Fixing the Post-Processing of the Image Failed Error

The file uploaded fine, but PHP crashed or timed out while WordPress was making the resized copies, and the browser got back a 5xx error instead of a result. Older WordPress says "Post-processing of the image failed likely because the server is busy or does not have enough resources." Current versions say "The server cannot process the image." The block editor shows "Media upload failed. If this is a photo or a large image, please scale it down and try again." All three describe the same failure: the image-processing step ran out of memory or time.

What happens before the message appears

This is the last stage of an upload. By this point PHP has already written the file to its temp directory (failures there are Missing a temporary folder and Failed to write file to disk), and WordPress has moved it into wp-content/uploads (failures there are could not be moved). Then:

1. WordPress creates the attachment post and sends the response header X-WP-Upload-Attachment-ID before it starts any image work.
2. wp_create_image_subsizes() scales the original down if it is larger than 2560 pixels, saving it as -scaled, and then generates every registered size.
3. Each size is saved to the attachment metadata as soon as it is made, in priority order: medium, large, thumbnail, medium_large, then any added by the theme and plugins.

If PHP dies during step 2 or 3, the browser gets a 5xx error but already has the attachment ID. Both uploaders then retry. The classic one calls admin-ajax.php?action=media-create-image-subsizes, and the block editor calls /wp/v2/media/<id>/post-process. Each retry continues from the sizes that are still missing. After five failures they give up, delete the attachment, and show the message.

This explains a symptom that confuses people. With a borderline image, a retry can sometimes succeed because it has less work left. So the same photo may fail once and upload fine the next time.

Cause 1: memory

GD loads the whole image into memory as uncompressed pixels, about 4 bytes per pixel or more. A 6000 × 4000 photo is 24 megapixels, so it needs roughly 100 MB just for the decoded copy, and each resize step adds a working copy on top. A JPEG's file size tells you nothing about this. What matters is its pixel dimensions.

Before it starts, the image editor raises PHP's memory to WP_MAX_MEMORY_LIMIT, which defaults to 256M. To give it more, set it in wp-config.php:

define( 'WP_MAX_MEMORY_LIMIT', '512M' );

This only works if the host lets memory_limit change at runtime. If it does not, WordPress keeps the current limit. The PHP error log shows Allowed memory size of … bytes exhausted from inside an image editor class when memory is the cause. More on these limits in increasing the memory limit.

Imagick does most of its allocation outside PHP's memory accounting, so memory_limit matters less with it, but ImageMagick's own resource limits apply. A host's policy.xml with tight memory or area limits produces the same failure.

Cause 2: time

Making ten or more sizes from a large photo can take longer than the server allows. Several limits can stop it:

• PHP's max_execution_time. On Linux it counts only CPU time, so time spent waiting on disk or network does not use it up.
• PHP-FPM's request_terminate_timeout, which kills the worker outright.
• A proxy or CDN timeout in front of the site. A Cloudflare 524 or a load balancer's 504 ends the request even while PHP is still working.

The server logs show which limit was hit. A proxy timeout leaves no PHP error at all, only the proxy's own error page and log entry.

Cause 3: too many sizes

Every size registered with add_image_size() means another resize on every upload. Page builders, sliders and WooCommerce themes often add five to fifteen sizes between them. List what is registered:

wp eval 'print_r( wp_get_registered_image_subsizes() );'

Remove sizes nothing uses, or switch them off at upload time:

add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
	unset( $sizes['1536x1536'], $sizes['2048x2048'] );
	return $sizes;
} );

Those two core sizes exist for responsive images on large screens. Keep them unless your theme never shows images that wide. The trade-offs are covered in image sizes.

Fixes that do not need server access

• Resize before uploading. A 2560-pixel image avoids both the scaling step and most of the memory cost.
• Switch editors. If GD runs out of memory and Imagick is installed, or Imagick hits its policy limits and GD would cope, change the order:

add_filter( 'wp_image_editors', fn () => array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' ) );

• Turn off the big-image scaling with add_filter( 'big_image_size_threshold', '__return_false' ); only if you resize before uploading anyway. It saves one resize, but every sub-size is made from the original either way, so memory use barely changes, and oversized originals would then be served as the full size.

Common mistakes

• Raising WP_MEMORY_LIMIT when image processing uses WP_MAX_MEMORY_LIMIT.
• Raising upload_max_filesize. The upload already succeeded, and that limit is a separate problem, covered in upload_max_filesize.
• Looking for the failed image in the library. After the last retry it has been deleted on purpose.

Verify

• Upload the photo that failed, in its original size, from both the Media Library and the block editor.
• Open the attachment and check that every size is listed. Missing sizes on older images can be rebuilt with regenerating thumbnails.
• Check the PHP error log for memory or timeout entries during the upload.