WordPress: fix “the server cannot process the image”

Start with a test that separates the file from the site

Your photo reaches the end of the progress bar, then WordPress reports that the server cannot process the image. The message sometimes suggests choosing a smaller image. This does not necessarily mean that the file exceeds the upload limit: the transfer may have succeeded while processing failed.

Save your post before trying again. Then open the media library in another tab and check whether the image is already there. Repeated attempts can create several entries, some of them incomplete. Do not delete these items immediately: note which one corresponds to the test and check whether it is already used on a page.

Prepare a small JPEG photo without confidential information, around 1,200 pixels wide. Upload it on its own. If it works, the site can process at least that file under those conditions. If it fails too, focus on the browser, session or hosting environment. This simple test avoids changing the configuration for a single damaged original.

Choose between the three approaches

The first approach is to prepare a copy of the image. It is suitable when some files work and others fail, especially very large photos, images exported by a particular application, or a newer format. You can often publish without changing the site.

The second approach checks the upload path and the browser. Use it when the same file works from another device, works in the media library but not in the post, or when the editor gets stuck before the upload finishes.

The third examines the server and site components. Prioritize it if several users fail with small, ordinary images, if the problem follows a migration, or if it happens on every upload. Keep the results of the first tests: they will help support and avoid starting the entire diagnosis again.

These approaches are not three fixes to apply automatically. Make one change, try the same reference file again, and observe the result before continuing.

Approach 1: reduce the dimensions of a copy

This path uses your usual photo application and a local copy of the image. It requires no server changes. The expected result is a suitable version that uploads successfully; you can still return to the original because you keep it separately.

1. Keep the original in a separate folder on your computer. Open a copy in your usual photo application and find the resize command. Enable the option to preserve the aspect ratio. For an article illustration displayed at a moderate width, try a width of 1,600 to 2,000 pixels, for example. Then adjust that value to the actual use and required quality.
2. Do not confuse the width in pixels with the file size in megabytes. A heavily compressed photo can still be huge once decoded. Reducing JPEG quality alone does not ease processing as much as also reducing the dimensions. An 8,000 × 6,000-pixel image contains sixteen times as many pixels as a 2,000 × 1,500 version.
3. Export the copy under a simple new name, then open it to check sharpness and orientation. Upload this version on its own to WordPress. If it works, you have an immediate solution for this publication and a clue about the site’s processing capacity.

Understand the 2,560-pixel suggestion

Some messages mention a dimension of 2,560 pixels. WordPress uses this value as the default threshold for its large-image scaling mechanism, depending on the processing path involved. This number is neither a universal ban on uploading a larger image nor a guarantee that a smaller one will work on every hosting environment.

Treat it as a troubleshooting reference. If your photo is 9,000 pixels wide, a copy suited to the site’s display will greatly reduce the work required. If your image is already 900 pixels wide and fails, repeating this recommendation will not help: look for another cause.

A portfolio intended to show artwork in detail may need larger files than a blog. Define that need before reducing the entire photo collection. Troubleshooting an upload does not justify overwriting originals or degrading images that are already published.

Re-export a file that appears normal

An image may open on your computer and still be difficult to process elsewhere. Its encoding, metadata or color profile may be involved. Try exporting it again from the application that opens it correctly. For a standard photo, choose JPEG and an sRGB profile when that setting is available. Keep sufficient quality and visually compare the two versions.

If the image contains transparency, use a format that preserves it, such as PNG, rather than automatically converting it to JPEG. An animation also requires suitable handling: exporting a single still image removes the motion. Present that version as a replacement illustration only if it suits your content.

Changing only the filename extension does not convert the file. A HEIC photo renamed to .jpg remains a HEIC photo. Use Export or Save As, then check the resulting format. If WordPress explicitly says that the file type is not allowed, address that format rejection before looking for a memory shortage.

Interpret the result without drawing too broad a conclusion

If a smaller copy works, note its dimensions, format and file size. Then try a second image from the same batch, prepared in the same way. This checks that your method works beyond a single file. To publish several photos, start with small batches and watch the media library.

If only re-exporting fixes the error while the dimensions stay similar, the original file or its encoding deserves more attention. This does not prove that the hosting environment lacks power. Keep the problematic original for a private review by support if the error needs a precise explanation.

If every image fails, even small, newly exported copies, stop making more conversions. You would mainly risk wasting time and accumulating duplicates. Move to the second path with the same reference file to obtain a useful comparison.

Approach 2: compare the media library and the editor

This path uses your editing account and requires no server changes. The expected result is to distinguish uploading through Media from uploading through a block; keep the same reference file. The original is preserved and any test draft remains unpublished.

1. In the administration area, open Media, then Add New Media File; the wording may vary slightly by version. Upload the reference file from that screen. Then return to a draft and select the image from the media library without uploading it a second time.
2. If this method works while adding the image directly in the Image block fails, you have a way to continue writing. Note which editor is involved: the block editor, classic editor or a page builder. They do not necessarily use the same technical path to upload and process media.
3. If the media library contains the image but the block does not display it, check the image URL and response before uploading it again. A display error, cache or inaccessible URL can cause a different problem after a successful upload. The useful question remains the same: at which stage does the operation stop working?

Account for processing in the browser

From WordPress 7.1 onward, media processing can run in a compatible browser, with a server-side fallback when the conditions are not met. The browser can then prepare images and thumbnails before they are stored. The WordPress version, browser and device therefore matter to the diagnosis.

Save the draft, then compare with an up-to-date browser on the same computer. Keep the same account, file and upload screen. Success in that context reveals a difference worth investigating; it does not immediately establish that the server has been repaired.

If the device is short on resources, close demanding applications and tabs before trying again. Avoid starting several large uploads at the same time. A different computer can provide a useful comparison. Bear in mind, however, that this may also change the network, browser and processing path: then try to isolate the difference responsible.

Investigate a browser-specific blockage

Try a browser profile without additional extensions. A privacy, filtering or page-modification extension may interfere with loading. Prefer this comparison to disabling every protection in your usual profile. A private window alone does not guarantee that all extensions and restrictions are absent.

For a more precise diagnosis, open the developer tools, then Console and Network. Retry a single upload and record the failing request, its status and the time. A 403 response, expired session or blocked script does not require the same fix as an image-processing error.

Browser processing also depends on the security rules served with the administration area. Have an error related to those rules examined by the relevant provider or developer. Do not remove the site’s entire security policy simply to make a message disappear. Share sanitized screenshots without cookies, tokens or responses containing private data.

Approach 3: record the server environment

This check requires an account with access to Site Health. It describes the active environment without modifying it. The expected result is a record of libraries and limits to compare with the log from the same test; no configuration rollback is needed for this inspection.

1. Under Tools, open Site Health, then Info. Review the sections on the server and media handling. Record the PHP version, image editor in use and available libraries. This information describes the environment; their presence does not prove that every format and operation works.
2. For server-side processing, WordPress relies in particular on Imagick or GD. The supported formats depend on how those libraries are installed. A server may process JPEG correctly and have difficulty with another format. Give support the real format of the failing file, as well as its extension.
3. If the problem follows a PHP version change or a migration, request a comparison with the previous environment. A missing library or a format that is no longer supported is a more precise lead than a general request for more memory. Do not arbitrarily replace Imagick with GD using a snippet found online.

Check memory, processing time and load

Check the logs available in the hosting control panel at the exact time of the test. A message reporting that a memory limit was reached warrants examining the PHP memory actually allocated to the site. A timeout or terminated process calls for a different check. If you cannot find the log, give support the time and ask for the recorded cause.

An upload limit and a memory limit serve two different purposes. Allowing a 64 MB file does not guarantee that the server can decode it, resize it and create all its variants. Raising only upload_max_filesize therefore does not fix a processing error that occurs after the transfer.

Have a limit adjusted only when the diagnosis supports it, within the bounds allowed by the hosting plan. Keep the previous value and check the result with the reference file. An unlimited value can worsen overload; it does not replace identifying abnormal processing or several competing tasks.

cPanel example: adjust PHP memory that is demonstrably insufficient

Use this procedure only if the log confirms PHP memory exhaustion during server-side processing and the hosting provider allows the adjustment. It requires access to the domain’s cPanel. A hosting process limit or an ImageMagick resource policy cannot necessarily be fixed through this field. The test copy must use its own directory and a separate PHP configuration: a second domain pointing to the same files does not isolate this intervention. Have that scope confirmed before changing the limit.

As a conditional example, if the relevant limit is indeed 128M and the plan allows 256M, you can compare the change to 256M on the copy. These numbers are not instructions for every site. Keep the previous value and the setting for the correct PHP version; do not choose an unlimited value.

The expected result combines an active limit checked in WordPress with successful processing of the same reference JPEG. A value saved in the panel is not enough. If the test has no benefit or causes a regression, return to the same field, restore the original value and apply it; do not delete configuration files to undo this single change.

1. In WordPress, open Tools, Site Health, Info, Server. Record the PHP version and memory limit; also note the limit reserved for administration if it is displayed.
2. In cPanel, search for MultiPHP INI Editor and open the Basic Mode tab.
3. Under Configure PHP INI basic settings, select the exact domain of the copy. Home Directory applies to the entire account: do not use it for this single-site test.
4. Record memory_limit, then enter the permitted value justified by the log, such as 256M in the example described. Do not change the other directives.
5. Click Apply, then reload the Server information in WordPress to check the active environment.
6. If the value does not change or the field does not exist, check the domain and the effective PHP configuration; do not increase the number again or force a change in another random file.
7. First check any entries already created by the previous test, then upload the reference JPEG just once and check its attachment details and variants.
8. Undo the change using the previous value and Apply if the result does not confirm this fix; keep the new log to investigate the remaining cause.

Check write access and available space

Processing must be able to read the file and write its results. Check available space in the hosting account, as well as any file quota. An account may lack the ability to create more files even if its space indicator still looks acceptable. Also ask support to check the temporary space used for image processing.

If the problem began after a restoration, have the owner and permissions of the upload directory checked. The process running PHP needs the appropriate access. The correct fix depends on the hosting setup; applying the same permissions everywhere is not a diagnosis.

Do not use 777 permissions across the site. Do not randomly delete thumbnail folders to recover space either. First identify unnecessary files, their use and the available backup. If the error directly mentions a missing temporary folder or inability to write, address that storage issue before restarting image transformations.

Isolate a component that handles images

Reconstruct recent changes: an optimization tool, automatic conversion, external storage, a theme or a new image size. A component may intervene after upload and cause a stage to fail that WordPress would otherwise have completed. Logs may name its file, but that name is still a clue to confirm.

On a test copy, use the reference file and normally deactivate just one suspect component. Test, reactivate it, then compare. The copy must reproduce the settings needed for diagnosis without accidentally sending files to shared production storage. If it uses a different server, keep that difference in mind.

For a live site, prepare the backup and rollback before intervening. Disabling a store’s entire storage chain may affect its public images. Start with the setting or component directly involved, then check whether the problem returns after reactivation when that test can be performed without putting visitors at risk.

Repair thumbnails only after fixing the cause

An entry can exist in the media library without all the expected sizes. After fixing the fault, first check a new upload. If it works, examine the older affected entries. You do not need to immediately reprocess several thousand media items.

With SSH and WP-CLI available, regeneration can be limited to the ID of the affected media item. Back up the files and database, confirm the correct installation, and replace 123 with the verified ID. On multisite, explicitly select the correct site. The command below targets missing sizes and requests that old thumbnails not be deleted. That setting does not replace a backup: regeneration also changes information associated with the media item. With this ID, the command writes immediately; it is not a dry run. Do not remove the number and thereby process the whole library.

This operation uses the server and does not recover a lost original. The source file must remain readable from that environment. If your media is stored externally, have the person responsible for that integration confirm the procedure before running the command. It may still fail if the cause has not been fixed. Then check the media item and the pages that use it. Without SSH, the guide to missing thumbnails details individual regeneration with ShortPixel’s reGenerate Thumbnails Advanced, without enabling its cleanup options. You can also ask your hosting provider to perform this targeted processing. A plugin does not replace fixing the fault first.

wp media regenerate 123 --only-missing --skip-delete

Validate the repair and keep a simple routine

Test a reference image, then an image representative of your normal use. Open their details in the media library, insert them in a draft, and check the preview on desktop and mobile. Look at sharpness, orientation, any transparency and image loading. The message disappearing is not enough if the visual result is wrong.

Delete only test duplicates that you have confirmed are unused. Keep originals outside the site and note the fix that worked. For future publications, prepare dimensions consistent with your pages: this makes uploading simpler and avoids sending unnecessarily large files to visitors.

A desktop image editor is often enough for this preparation, without adding a WordPress plugin. A regeneration plugin may be useful afterward for an identified need, but it still depends on available resources and should be tried on one media item before any bulk processing. It does not repair a full disk or a broken server library.

If you need to send the case to support

Send the exact error text, the time with its time zone, the file’s dimensions and format, and the results from the small reference JPEG. Specify whether uploading fails in the media library, in the editor or in both. Add the WordPress version and browser used, then any known recent changes.

Ask which stage fails: receiving, decoding, transforming, writing or finalizing. A reproducible example and these comparative results make for a more useful response than a request to “unblock images.” Send the problematic file through a private channel if it contains personal information.

On managed hosting, especially when you have no access to PHP or files, stay within the settings actually available and use the service’s support. You can still prepare a suitable copy and compare upload paths. Server changes must be made by the person who administers that environment.

Compare server-side support for a format

On a copy with WP-CLI, the maintainer can ask WordPress whether a server image editor supports a MIME type. The diagnostic below compares JPEG and WebP without uploading a file or generating a thumbnail. Replace the path and domain with those of the copy; on multisite, confirm the subsite.

Reported support does not prove that the particular image can be decoded, that there is enough memory or that the directory accepts the variants. However, a WebP refusal alongside JPEG support gives you a specific request for the host: check the libraries of the PHP version actually used.

Take care with the comparison: WP-CLI uses the terminal’s PHP, which may differ from web PHP. Compare its version with the Site Health information. Browser processing in WordPress 7.1 is yet another path; success in the editor therefore does not automatically validate this server environment. This check requires no additional plugin and does not justify globally forcing the choice of Imagick or GD.

wp --path='/chemin/copie' --url='https://copie.example.test' eval 'foreach (array("image/jpeg", "image/webp") as $mime) { echo $mime . ": " . (wp_image_editor_supports(array("mime_type" => $mime)) ? "support annonce" : "support non annonce") . PHP_EOL; }'