Is there a difference between JPG and JPEG?

No. .jpg and .jpeg are two extensions for one format. WordPress core maps jpg|jpeg|jpe to the MIME type image/jpeg. Mozilla’s MDN lists .jpg, .jpeg, .jfif, .pjpeg and .pjp as extensions for that same type. Rename a file from one to the other and the image is unchanged, down to the last byte.

People keep asking because of what they run into. One spelling uploads and the other doesn’t, or a WebP plugin converts some photos and skips others. Real things cause those problems, and none of them is the extension. Most come down to a plugin, a form field or a server setting. The same pattern shows up in our guide to WordPress plugins that are not working.

What actually decides a JPEG’s quality and size

The quality and size of a JPEG come from the encoded image data. The filename has no part in it. The compression level, the pixel dimensions and the number of times the file has been re-saved all live inside the file. The extension is a label on the outside.

JPEG is lossy. Each time it compresses, it throws away some detail, and editing and re-saving a JPEG again and again makes it worse. WordPress’s own “Image size and quality” documentation describes the trade: JPEG gives up detail for a smaller file, which suits photographs. No benchmark shows a quality, size or speed difference between the same file saved as .jpg and as .jpeg. Nothing about the format would create one.

Why renaming a file is not converting it

Renaming is fine between .jpg and .jpeg because both hold the same kind of data. Renaming across formats is where trouble starts. An iPhone HEIC photo, a PNG or a WebP renamed to photo.jpg is still a HEIC, PNG or WebP inside. Now its label is wrong.

WordPress checks what a file actually is, not only what it is called. So a fake JPEG often fails at upload with “Sorry, this file type is not permitted for security reasons.” If one gets through, it can show up blank, or fail later when an optimization plugin tries to compress or resize it. Files half-converted by an online tool or an old export setting fail the same way.

The fix is to open the original in an image editor, export a real JPEG and upload that. Don’t add ALLOW_UNFILTERED_UPLOADS to wp-config.php to force it in. That constant turns off file-type filtering for every upload on the site, and the broken file behind the error is still broken.

Why a site accepts .jpg but rejects .jpeg

When only one spelling fails, something between you and WordPress core is checking the extension against its own list. Core accepts both. A form plugin, a WooCommerce product upload field, a security plugin or a custom validator may not.

Some WooCommerce extensions have you set allowed file types for each field. The documentation for All In One Files Upload for WooCommerce lists JPEG and JPG as separate options. If someone ticked one and not the other, the field rejects half your customers’ photos. You fix it in the settings, not in the file:

• In a field that asks for extensions, allow both jpg and jpeg.
• In a field that asks for MIME types, enter image/jpeg. That one type covers both spellings.
• If you write upload code, check the file’s contents and MIME type, not just the characters after the dot.

Sometimes the cause is a plugin bug. In a 2022 WordPress.org support thread, a user found that the Converter for Media plugin was converting their .jpg files to WebP but skipping .jpeg files that held the same data. The plugin’s author could not reproduce it. The user suggested renaming old .jpeg files to .jpg, and the author strongly advised against it. A later section explains why.

Renaming the one file you are uploading can get you past a badly set up allow-list. It repairs nothing, so fix the setting.

When both fail, the extension was never the cause

If a small, ordinary JPEG with a simple name also fails, stop thinking about the extension. The error messages are vague (“HTTP error”, “The server cannot process the image”), but the causes follow a familiar order. The order below comes from practitioner reports, not from measured data:

1. Pixel dimensions too large. On upload, WordPress creates several smaller copies of each image, plus any extra sizes your theme adds. A photo straight off the camera can run out of PHP memory during that step even after you compress its megabytes. Resize it before uploading. If Allowed memory size ... exhausted shows up in debug.log, see the memory fixes in our white screen guide. Raising WordPress’s limit does nothing if the server’s PHP limit is lower.
2. Image library failure. The server processes images with Imagick or GD. If ImagickException: unable to read image data appears in the log, try switching to GD, stripping unusual EXIF metadata or re-exporting the file.
3. A fake or corrupt file. See the renaming section above.
4. Upload limits. PHP’s upload_max_filesize and post_max_size cap the size of an upload. On Nginx, client_max_body_size rejects large requests with a 413 before PHP ever sees them, so changing PHP alone won’t help. The displayed maximum on Media → Add New shows the PHP side.
5. Plugin or theme conflicts. Test with the Health Check & Troubleshooting plugin, which Learn WordPress covers for conflict testing. Don’t switch everything off on a live store.
6. Permissions or disk space. move_uploaded_file(): Unable to move '/tmp/...' usually follows a migration. Directories should be 755 and files 644. 777 is never the fix.
7. Security rules. A 403 during upload often means a ModSecurity or firewall rule. Ask your host to whitelist that specific rule rather than turn the firewall off.

One more: WordPress.com’s support docs note that “Unexpected response from the server” often means the upload worked anyway. Check Media → Library before you upload again, or you’ll end up with duplicates.

If you’d rather not work through that list yourself, SiteSelf can track down the upload failure on your live site and report what it found and changed. Server limits, logs and file permissions need hosting (SSH) access, not just the connector plugin.

Should you rename your existing .jpeg files to .jpg?

No. Renaming is safe for the image and risky for the site. /photo.jpg and /photo.jpeg are different URLs. Posts with hardcoded image links, CDN caches, download links, product imports and other sites linking to your images all point at the old one. Linux servers also treat file paths as case-sensitive, so .JPG and .jpg can be two different files there.

A mixed library looks messy but costs nothing. Pick one convention for new uploads, usually lowercase .jpg, and leave old files alone. If you really must rename something, update every reference to it and redirect the old URL.

The image decisions that matter more

Choosing between the two spellings changes nothing. These choices do:

• JPEG or PNG. Use JPEG for photographs. JPEG cannot be transparent, so a “transparent background JPG” doesn’t exist. Logos, screenshots, line art and anything with sharp text belong in PNG or SVG. Keep the vector master file for a logo.
• JPEG or WebP and AVIF. WordPress 6.5 added AVIF support, and the Make WordPress Core announcement says AVIF images “can be up to 50% smaller than JPEGs” at the same quality. “Up to” means best case, and your savings depend on the photo and the encoder. The usual approach is to upload JPEGs, let a plugin serve WebP or AVIF copies with JPEG fallbacks, and keep the originals.
• Dimensions and compression. A 6,000-pixel photo in a 1,200-pixel column wastes bandwidth whatever its extension. Resize it before uploading, then compress it.

Modern formats explain why a site can show .jpg, .jpeg, .webp and .avif files side by side. Those are copies made for delivery. They don’t mean the two JPEG spellings behave differently. One practical exception: WooCommerce’s mobile app does not support WebP, and its docs recommend exporting product images as .jpg or .png.