Key takeaways
- WordPress core maps jpg, jpeg and jpe to the same MIME type, image/jpeg, so thumbnails, srcset and editing work the same for both.
- Renaming a HEIC, PNG or WebP file to .jpg does not make it a JPEG. Files like that get rejected by WordPress, show up blank or break bulk optimizers later.
- If .jpg uploads but .jpeg does not, check the field or plugin allow-list first. Add both extensions, or use image/jpeg in a MIME field.
- Don’t mass-rename old .jpeg files. The image stays the same but the URL changes, and links, caches and imports break.
- The choices that change file size are compression, pixel dimensions and format. WordPress Core says AVIF can be up to 50% smaller than 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
jpgandjpeg. - 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:
- 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 ... exhaustedshows 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. - Image library failure. The server processes images with Imagick or GD. If
ImagickException: unable to read image dataappears in the log, try switching to GD, stripping unusual EXIF metadata or re-exporting the file. - A fake or corrupt file. See the renaming section above.
- Upload limits. PHP’s
upload_max_filesizeandpost_max_sizecap the size of an upload. On Nginx,client_max_body_sizerejects 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. - 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.
- 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. - 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.

Frequently asked questions
How do I convert a JPG to a JPEG?
There is nothing to convert. If the file is a real JPEG, it is already both. Renaming it changes the label and the URL, not the image. You only need a real conversion when the file is actually another format, such as HEIC, PNG or WebP.
Is JPG the same as JPEG 2000?
No. JPEG 2000 is a separate standard with its own extensions, such as .jp2. It is not what a camera or phone produces when it saves a .jpg, and WordPress does not treat it as an ordinary JPEG.
Does renaming .jpeg to .jpg reduce quality?
No. Renaming leaves the image data alone. Quality drops when a JPEG is re-encoded, for example when you edit it and save it again or run it through a compressor at a lower quality setting.
Does uppercase .JPG cause problems?
It can, and the problem is the URL, not the image. On a case-sensitive server, photo.JPG and photo.jpg are different paths, so a link typed in lowercase can break. Stick to lowercase filenames for new uploads.
Can I upload only WebP and skip JPEG entirely?
You can, but most practitioners advise against it. Uploading JPEGs and letting a plugin create WebP or AVIF copies keeps a fallback for tools that don’t handle the newer formats, and lets you regenerate everything later. Test the fallbacks before you delete any originals.
Leave a Reply