{"id":1325,"date":"2026-09-24T16:20:18","date_gmt":"2026-09-24T16:20:18","guid":{"rendered":"https:\/\/www.ahosting.net\/blog\/?p=1325"},"modified":"2026-09-25T16:45:00","modified_gmt":"2026-09-25T16:45:00","slug":"the-server-cannot-process-the-image","status":"publish","type":"post","link":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/","title":{"rendered":"The Server Cannot Process the Image: What WordPress Is Telling You"},"content":{"rendered":"\n<script type=\"application\/ld+json\">{\"@context\": \"https:\/\/schema.org\", \"@type\": \"FAQPage\", \"mainEntity\": [{\"@type\": \"Question\", \"name\": \"How do I fix the server cannot process the image error in WordPress?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Typically by finding out which limit the resize ran into rather than by retrying the same file. The upload itself usually succeeded, so first check the media library. A photo that stayed without its thumbnails points outside PHP, and one that vanished after a pause was deleted by WordPress after five failed retries. Then read the PHP error log for an allowed memory size line. If one is there, the image needs more PHP memory than the request was allowed. If the log is silent, the process was stopped from outside PHP, by the account memory cap or a timeout. Shrinking the photo to 2560 pixels on its long edge before uploading fixes either case.\"}}, {\"@type\": \"Question\", \"name\": \"Why does WordPress say the server cannot process the image for ordinary photos in 2026?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Specifically because ordinary photos are now very large once decoded. A current phone camera can save a 48 megapixel image, and while the file on disk may be only a few megabytes, the resizer has to unpack every pixel into memory before it can shrink it. In our measurement that single step took a quarter of a gigabyte for a 48 megapixel photo. WordPress then makes up to seven resized copies from it. The error is the message WordPress shows when the server gave up partway through that work.\"}}, {\"@type\": \"Question\", \"name\": \"Is my photo still uploaded when the server cannot process the image?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"In practice it arrives, but it may not stay. WordPress saves the file and creates its media library entry before it starts resizing, and it reports the entry number back to the browser in a response header for exactly this situation. The Media Library uploader then asks the server five more times to finish the resized copies. If every attempt fails, it asks the server to delete the entry and its files, which is why a photo can appear briefly and then vanish. When no retries ran, the original usually remains without its copies.\"}}, {\"@type\": \"Question\", \"name\": \"Does AHosting WordPress hosting have enough memory to avoid the server cannot process the image?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"That said, memory is only one of the limits involved, so it is worth being precise. AHosting WordPress plans publish a PHP memory limit of up to 512 MB and account memory of 2, 3 or 4 GB depending on the plan. In our measurement a 48 megapixel photo peaked at about a quarter of a gigabyte during resizing, which fits comfortably inside both once the PHP limit is set above 256 MB. What can still fail is several large uploads at once, because every site on the account shares the same memory cap, and a timeout on a very slow resize.\"}}, {\"@type\": \"Question\", \"name\": \"GD vs Imagick: which image library fails less often with large photo uploads?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"By contrast with the usual advice, neither is simply safer, because they fail in different places. GD, when PHP was built with its bundled copy, counts every decoded pixel against the PHP memory limit, so it fails early and leaves an allowed memory size line in the error log. Imagick allocates outside that limit, so PHP never objects, but the process still counts against the account memory cap and can be stopped there without any PHP error at all. The library that fails less is the one whose limit has more room.\"}}, {\"@type\": \"Question\", \"name\": \"Block editor vs Media Library: why does only one of them show this upload error?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Notably WordPress 7.1 changed where resizing happens. On a site served over HTTPS, in a browser that allows it, the block editor now resizes images inside the browser and sends the finished copies to the server, so the server never has to decode the full photo. The Media Library uploader still sends the original and resizes on the server. So the same photo can fail from Media and succeed from the editor. The browser console in the editor prints a line saying which path it used.\"}}, {\"@type\": \"Question\", \"name\": \"Will an AHosting plan upgrade fix the server cannot process the image in 2026?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Ultimately only if the limit you hit belongs to the plan, and the error log tells you whether it does. A larger plan raises the account memory cap and the number of processes that can run at once, which helps when several large uploads or a busy site share the account. It does not help when the PHP memory limit is set below what one photo needs, because that is a setting you can raise yourself within the published ceiling. Check that setting first, and upgrade only when the account cap is the proven limit.\"}}, {\"@type\": \"Question\", \"name\": \"Can I raise the memory limit myself so large photo uploads stop failing?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Indeed you usually can, and it helps to know what WordPress already does. Before image work it raises the limit to the value of the WP_MAX_MEMORY_LIMIT constant, which is 256 MB unless your PHP limit is higher, so raising the PHP limit from 128 to 256 changes nothing for images. Set the PHP limit above 256 MB and WordPress adopts the higher figure on its own. Defining the constant in wp-config.php is the other route, where PHP may raise its own limit. Neither can exceed the account cap.\"}}, {\"@type\": \"Question\", \"name\": \"How do I check which image library my AHosting WordPress site is using?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Fortunately WordPress will tell you without any code. Open Tools, then Site Health, then the Info tab, and expand Media Handling. The Active editor line names the library WordPress picked, the GD version line shows whether GD is the bundled build, and when Imagick is loaded its resource limits are listed too. On an AHosting account the extension list for each PHP version is in Select PHP Version in cPanel, so turning Imagick on or off for the version you run is a checkbox.\"}}, {\"@type\": \"Question\", \"name\": \"Does the server cannot process the image error affect SEO or page speed in 2026?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Interestingly the error itself affects nothing visitors or crawlers see, because it only happens in the dashboard. What it affects is what you publish next. A photo that uploads without its resized copies, or one that is re-uploaded at full size to get around the error, can end up served to phones at many times the size they need, and oversized images are among the most common causes of a slow largest contentful paint. So fix the resize, not the symptom, and check that the resized copies exist.\"}}]}<\/script>\n\n\n<div class=\"wp-block-aioseo-table-of-contents\"><ul><li><a class=\"aioseo-toc-item\" href=\"#aioseo-what-the-server-cannot-process-the-image-actually-means\">What The Server Cannot Process the Image Actually Means<\/a><ul><li><a class=\"aioseo-toc-item\" href=\"#aioseo-the-upload-worked-the-resizing-did-not\">The Upload Worked. The Resizing Did Not.<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-three-wordings-for-one-failure\">Three Wordings for One Failure<\/a><\/li><\/ul><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-what-wordpress-does-after-the-server-cannot-process-the-image\">What WordPress Does After the Server Cannot Process the Image<\/a><ul><li><a class=\"aioseo-toc-item\" href=\"#aioseo-a-header-that-carries-the-media-entry-number\">A Header That Carries the Media Entry Number<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-five-retries-then-the-upload-is-deleted\">Five Retries, Then the Upload Is Deleted<\/a><\/li><\/ul><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-why-the-server-cannot-process-the-image-in-one-screen-but-not-another\">Why the Server Cannot Process the Image in One Screen but Not Another<\/a><ul><li><a class=\"aioseo-toc-item\" href=\"#aioseo-the-conditions-for-in-browser-resizing\">The Conditions for In-Browser Resizing<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-a-console-line-that-tells-you-which-path-ran\">A Console Line That Tells You Which Path Ran<\/a><\/li><\/ul><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-the-memory-bill-of-one-photo-upload\">The Memory Bill of One Photo Upload<\/a><ul><li><a class=\"aioseo-toc-item\" href=\"#aioseo-what-we-measured\">What We Measured<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-why-your-error-log-may-say-nothing\">Why Your Error Log May Say Nothing<\/a><\/li><\/ul><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-which-limit-stops-the-server-from-processing-the-image\">Which Limit Stops the Server From Processing the Image<\/a><ul><li><a class=\"aioseo-toc-item\" href=\"#aioseo-php-memory-and-the-256-mb-wordpress-already-asks-for\">PHP Memory, and the 256 MB WordPress Already Asks For<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-the-account-memory-cap\">The Account Memory Cap<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-the-clock\">The Clock<\/a><\/li><\/ul><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-how-to-fix-the-server-cannot-process-the-image-in-order\">How to Fix The Server Cannot Process the Image, in Order<\/a><ul><li><a class=\"aioseo-toc-item\" href=\"#aioseo-seven-steps-when-the-server-cannot-process-the-image\">Seven Steps When the Server Cannot Process the Image<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-fixes-by-what-you-found\">Fixes by What You Found<\/a><\/li><\/ul><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-when-the-fix-is-more-headroom\">When the Fix Is More Headroom<\/a><ul><li><a class=\"aioseo-toc-item\" href=\"#aioseo-where-the-work-stops-being-yours\">Where the Work Stops Being Yours<\/a><\/li><\/ul><\/li><li><a class=\"aioseo-toc-item\" href=\"#faq-the-server-cannot-process-the-image\">Frequently Asked Questions About The Server Cannot Process the Image<\/a><ul><li><a class=\"aioseo-toc-item\" href=\"#faq-how-do-i-fix-the-server-cannot-process-the-image-in-wordpress\">How do I fix the server cannot process the image error in WordPress?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#faq-why-does-the-server-cannot-process-the-image-appear-in-2026\">Why does WordPress say the server cannot process the image for ordinary photos in 2026?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#faq-is-the-image-uploaded-when-the-server-cannot-process-the-image\">Is my photo still uploaded when the server cannot process the image?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#faq-does-ahosting-have-enough-memory-to-stop-the-server-cannot-process-the-image\">Does AHosting WordPress hosting have enough memory to avoid the server cannot process the image?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#faq-gd-vs-imagick-which-fails-less-on-shared-hosting\">GD vs Imagick: which image library fails less often with large photo uploads?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#faq-block-editor-vs-media-library-why-only-one-shows-the-error\">Block editor vs Media Library: why does only one of them show this upload error?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#faq-will-an-ahosting-upgrade-fix-the-server-cannot-process-the-image-2026\">Will an AHosting plan upgrade fix the server cannot process the image in 2026?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#faq-can-i-raise-the-memory-limit-myself-for-large-photo-uploads\">Can I raise the memory limit myself so large photo uploads stop failing?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#faq-how-do-i-check-which-image-library-my-ahosting-account-uses\">How do I check which image library my AHosting WordPress site is using?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#faq-does-the-server-cannot-process-the-image-affect-seo-in-2026\">Does the server cannot process the image error affect SEO or page speed in 2026?<\/a><\/li><\/ul><\/li><\/ul><\/div>\n\n\n<div class=\"ah-tldr\">\n  <span class=\"ah-tldr-badge\">TL;DR<\/span>\n  <p>When WordPress says the server cannot process the image, the upload almost always worked. What failed is the resizing that follows, which unpacks every pixel of the photo into memory before making up to seven smaller copies. We measured that at about a quarter of a gigabyte for a 48 megapixel phone photo. Since WordPress 7.1 the block editor can do the resizing in your browser instead, while the Media Library still does it on the server, so the same photo can fail in one and work in the other. The fix depends on which limit stopped the resize, and your error log usually says which.<\/p>\n<\/div>\n\n\n\n<h2 id=\"aioseo-what-the-server-cannot-process-the-image-actually-means\" class=\"wp-block-heading\">What The Server Cannot Process the Image Actually Means<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">When WordPress tells you <em>the server cannot process the image<\/em>, it is describing the second half of an upload, not the first. The file reached your site. WordPress saved it and created its media library entry before it did anything else. Then it began making the smaller copies every theme and page builder asks for, and somewhere in that work the request ended in a server error. The message is what the uploader prints when that happens. It is a guess about the cause, and the guess is often right: a busy server, or one without enough resources for the job it was just given.<\/p>\n\n\n\n<figure class=\"wp-block-audio\"><audio controls src=\"https:\/\/www.ahosting.net\/blog\/wp-content\/uploads\/2026\/09\/PODCAST-the-server-cannot-process-the-image.m4a\"><\/audio><figcaption class=\"wp-element-caption\">Listen: when WordPress says the server cannot process the image, the upload usually worked and the resizing did not, and what is left in the media library tells you which limit it hit. By Matt Chrust, Director of Business Development, AHosting.<\/figcaption><\/figure>\n\n\n\n<h3 id=\"aioseo-the-upload-worked-the-resizing-did-not\" class=\"wp-block-heading\">The Upload Worked. The Resizing Did Not.<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">This distinction decides everything that follows. A failed upload means the file never arrived, which is a question of file size limits and is covered in our guide to <a href=\"https:\/\/www.ahosting.net\/blog\/the-link-you-followed-has-expired\/\">the link you followed has expired<\/a>. A failed resize means the file arrived and the server then ran out of something while working on it. For a photo larger than 2560 pixels on its long edge, WordPress first makes a scaled copy at that size, then six more copies at the default sizes of 150, 300, 768, 1024, 1536 and 2048 pixels. That is seven images written from one upload, before any theme adds sizes of its own.<\/p>\n\n\n\n<h3 id=\"aioseo-three-wordings-for-one-failure\" class=\"wp-block-heading\">Three Wordings for One Failure<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">You may be searching for an older version of this message. WordPress 5.3 introduced it as <em>Post-processing of the image failed<\/em>, followed by advice to scale a large photo down. Versions 5.4 to 5.8 said <em>Post-processing of the image failed likely because the server is busy or does not have enough resources<\/em>. Since 5.9 the wording has been <em>The server cannot process the image. This can happen if the server is busy or does not have enough resources to complete the task. Uploading a smaller image may help. Suggested maximum size is 2560 pixels.<\/em> All three come from the same code path, and everything below applies to each of them.<\/p>\n\n\n\n<h2 id=\"aioseo-what-wordpress-does-after-the-server-cannot-process-the-image\" class=\"wp-block-heading\">What WordPress Does After the Server Cannot Process the Image<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Most guides stop at the message. The code behind it is more useful, because it explains two things people report and cannot account for: photos that appear in the library and then disappear, and failures that happen instantly with no attempt to recover. Both are deliberate, and both are visible if you know where to look.<\/p>\n\n\n\n<figure class=\"wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio\"><div class=\"wp-block-embed__wrapper\">\n<iframe loading=\"lazy\" title=\"The Server Cannot Process the Image in WordPress: Why (2026)\" width=\"500\" height=\"281\" src=\"https:\/\/www.youtube-nocookie.com\/embed\/SkM6Af1spGs?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen><\/iframe>\n<\/div><\/figure>\n\n\n\n<h3 id=\"aioseo-a-header-that-carries-the-media-entry-number\" class=\"wp-block-heading\">A Header That Carries the Media Entry Number<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Just before WordPress starts resizing, it sends a response header named <code>X-WP-Upload-Attachment-ID<\/code> carrying the number of the media entry it has just created. The core source comments explain why: it lets the browser resume creating the resized copies after a fatal PHP error. If resizing then crashes the request, the error response still carries that header, and the uploader in your browser knows exactly which entry was left half finished.<\/p>\n\n\n\n<h3 id=\"aioseo-five-retries-then-the-upload-is-deleted\" class=\"wp-block-heading\">Five Retries, Then the Upload Is Deleted<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In the Media Library uploader, both the Add New screen and the media window inside the editor, a server error in the 500 range with that header present starts a recovery loop. The browser asks the server to create only the missing copies, and if that request fails too, it asks again, up to five times. Should any attempt succeed, the upload completes as if nothing happened. If all five fail, the browser sends one last request asking the server to delete the entry and its files, which the server does only if the entry is less than ten minutes old and you are allowed to delete it. Then the error appears. That is the photo that was there a moment ago.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When the header is missing, there is no loop at all. WordPress holds its headers until it replies, so a PHP process stopped from outside never sends one, and neither does an error page from a proxy, a firewall rule or the web server. So what is left in your library is a diagnosis. A photo that vanished after retries points at a PHP error, which the error log will name. A photo that stayed without its thumbnails points outside PHP.<\/p>\n\n\n\n<div class=\"ah-infographic\">\n  <svg viewBox=\"0 0 720 400\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" role=\"img\" aria-label=\"What the WordPress Media Library uploader does when the server cannot process the image: the original is saved and given a media library entry first, resizing then fails with a server error, the browser reads the entry number from a response header and asks the server to finish the resized copies up to five more times, and after the fifth failure it asks the server to delete the entry and its files and shows the error.\">\n    <title>What happens after the server cannot process the image<\/title>\n    <desc>Step one, the photo arrives and WordPress saves the original file and creates its media library entry. Step two, WordPress starts making the resized copies and the request ends in a server error in the 500 range. Step three, if the response carried the X-WP-Upload-Attachment-ID header, the browser asks the server to create the missing copies again, up to five times. If one attempt succeeds, the upload completes normally. If all five fail, the browser asks the server to delete the entry and its files, which it does only if the entry is less than ten minutes old, and the error message is shown. If the header was missing, because the PHP process was stopped from outside or something other than WordPress answered, the browser shows the error with no retries, and the original stays without its resized copies.<\/desc>\n    <rect x=\"0\" y=\"0\" width=\"720\" height=\"400\" fill=\"#0f172a\"\/>\n    <text x=\"32\" y=\"40\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"19\" font-weight=\"700\">The upload worked. The resizing did not.<\/text>\n    <text x=\"32\" y=\"63\" fill=\"#eef3ff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"13\">What the Media Library uploader does in WordPress 7.1 when resizing fails.<\/text>\n    <rect x=\"32\" y=\"86\" width=\"200\" height=\"74\" fill=\"#1e293b\" stroke=\"#2563eb\" stroke-width=\"2\"\/>\n    <text x=\"46\" y=\"110\" fill=\"#60a5fa\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"12\" font-weight=\"700\">1. Original saved<\/text>\n    <text x=\"46\" y=\"130\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"11\">File written to uploads and a<\/text>\n    <text x=\"46\" y=\"147\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"11\">media entry created first<\/text>\n    <rect x=\"260\" y=\"86\" width=\"200\" height=\"74\" fill=\"#1e293b\" stroke=\"#f59e0b\" stroke-width=\"2\"\/>\n    <text x=\"274\" y=\"110\" fill=\"#f59e0b\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"12\" font-weight=\"700\">2. Resizing fails<\/text>\n    <text x=\"274\" y=\"130\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"11\">Memory, a process cap or the<\/text>\n    <text x=\"274\" y=\"147\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"11\">clock ends it with a 5xx<\/text>\n    <rect x=\"488\" y=\"86\" width=\"200\" height=\"74\" fill=\"#1e293b\" stroke=\"#2563eb\" stroke-width=\"2\"\/>\n    <text x=\"502\" y=\"110\" fill=\"#60a5fa\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"12\" font-weight=\"700\">3. Entry ID read<\/text>\n    <text x=\"502\" y=\"130\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"11\">The browser looks for the<\/text>\n    <text x=\"502\" y=\"147\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"11\">X-WP-Upload-Attachment-ID header<\/text>\n    <rect x=\"32\" y=\"188\" width=\"320\" height=\"120\" fill=\"#1e293b\" stroke=\"#334155\" stroke-width=\"1\"\/>\n    <text x=\"48\" y=\"214\" fill=\"#60a5fa\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"13\" font-weight=\"700\">Header present<\/text>\n    <text x=\"48\" y=\"240\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"12\">Up to 5 more requests to finish<\/text>\n    <text x=\"48\" y=\"262\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"12\">the resized copies<\/text>\n    <text x=\"48\" y=\"286\" fill=\"#93c5fd\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"11\">All 5 fail: entry deleted if under 10 minutes<\/text>\n    <text x=\"48\" y=\"301\" fill=\"#93c5fd\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"11\">old, then the error is shown<\/text>\n    <rect x=\"368\" y=\"188\" width=\"320\" height=\"120\" fill=\"#1e293b\" stroke=\"#f59e0b\" stroke-width=\"2\"\/>\n    <text x=\"384\" y=\"214\" fill=\"#f59e0b\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"13\" font-weight=\"700\">Header missing<\/text>\n    <text x=\"384\" y=\"240\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"12\">The process was stopped from outside,<\/text>\n    <text x=\"384\" y=\"262\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"12\">or a proxy or security rule answered<\/text>\n    <text x=\"384\" y=\"286\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"12\">No retries: the original stays<\/text>\n    <text x=\"384\" y=\"301\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"12\">without its resized copies<\/text>\n    <text x=\"32\" y=\"346\" fill=\"#ffffff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"13\" font-weight=\"700\">After five failures, the original is deleted along with its entry.<\/text>\n    <text x=\"32\" y=\"368\" fill=\"#eef3ff\" font-family=\"Helvetica, Arial, sans-serif\" font-size=\"12\">The block editor in 7.1 uses a different queue and can resize in the browser instead.<\/text>\n  <\/svg>\n<\/div>\n\n\n\n<h2 id=\"aioseo-why-the-server-cannot-process-the-image-in-one-screen-but-not-another\" class=\"wp-block-heading\">Why the Server Cannot Process the Image in One Screen but Not Another<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress 7.1 added something no current guide to this error mentions, and it changes the diagnosis. The block editor can now do the resizing in your browser, using a WebAssembly build of the <a href=\"https:\/\/www.libvips.org\/\" target=\"_blank\" rel=\"noopener\">libvips image library<\/a> running in a background worker. When it does, the server receives copies that are already the right sizes and never decodes the full photo. The Media Library uploader has not changed: it still sends the original and resizes on the server. So the same photo, on the same site, can fail from Media and upload cleanly from the editor.<\/p>\n\n\n\n<h3 id=\"aioseo-the-conditions-for-in-browser-resizing\" class=\"wp-block-heading\">The Conditions for In-Browser Resizing<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In-browser resizing is switched on only when every condition below is met. Most of them are decided by your browser or your connection to the site, which is why two people on the same site can see different results. The table is read from the WordPress 7.1.2 source.<\/p>\n\n\n\n<figure class=\"wp-block-table ah-ladder\"><table><thead><tr><th>Condition<\/th><th>Why it matters<\/th><th>If it is not met<\/th><\/tr><\/thead><tbody><tr><td>The dashboard is served over HTTPS<\/td><td>WordPress checks this on the server before offering the feature at all<\/td><td>Server-side resizing for everyone<\/td><\/tr><tr><td>A Chromium browser from version 137<\/td><td>WordPress sends the <a href=\"https:\/\/chromestatus.com\/feature\/5141940204208128\" target=\"_blank\" rel=\"noopener\">Document-Isolation-Policy header<\/a> only to Chrome, Edge and other Chromium browsers at 137 or later<\/td><td>No isolation, so the next check fails<\/td><\/tr><tr><td>The page is cross-origin isolated<\/td><td>The resizer needs shared memory between threads, which browsers allow only on isolated pages<\/td><td>Server-side resizing<\/td><\/tr><tr><td>At least 2 CPU cores and more than 2 GB of device memory<\/td><td>The editor checks the device before starting the resizer<\/td><td>Server-side resizing<\/td><\/tr><tr><td>Data saver is off and the connection is faster than 2G<\/td><td>The resizer downloads a large WebAssembly module<\/td><td>Server-side resizing<\/td><\/tr><tr><td>The Content Security Policy allows blob: workers<\/td><td>The resizer runs in a worker created from a blob, which a strict worker-src rule blocks<\/td><td>Server-side resizing<\/td><\/tr><tr><td>A standard editor screen<\/td><td>Page builders that replace the editor screen are skipped on purpose<\/td><td>Server-side resizing<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\">When WordPress 7.1 resizes uploads in the browser instead of on the server. Every row must pass; a single failure sends the original photo to the server, where the error can occur.<\/figcaption><\/figure>\n\n\n\n<h3 id=\"aioseo-a-console-line-that-tells-you-which-path-ran\" class=\"wp-block-heading\">A Console Line That Tells You Which Path Ran<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">You do not have to guess which path an upload took. Open the block editor, open your browser\u2019s developer console, and upload an image. If the browser could not do the work, the editor logs a line beginning <em>Client-side media processing unavailable<\/em>, followed by the reason and the words <em>Using server-side processing<\/em>. The reason is precise. The most common one names the missing shared memory feature, which on <a href=\"https:\/\/caniuse.com\/sharedarraybuffer\" target=\"_blank\" rel=\"noopener\">current browser support tables<\/a> is available only on isolated pages. Safari and Firefox users will usually see it, because WordPress sends its isolation header only to Chromium. No line means the browser did the resizing.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">One consequence is worth stating plainly: switching to Chrome is a legitimate workaround when the server cannot process the image, not a superstition. It moves the heavy work off the server entirely. The header WordPress sends is defined in the <a href=\"https:\/\/wicg.github.io\/document-isolation-policy\/\" target=\"_blank\" rel=\"noopener\">Document Isolation Policy specification<\/a>, and a proxy that strips unfamiliar response headers from the dashboard will quietly turn the feature off for everyone.<\/p>\n\n\n\n<h2 id=\"aioseo-the-memory-bill-of-one-photo-upload\" class=\"wp-block-heading\">The Memory Bill of One Photo Upload<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The size of the file you upload tells you very little about the work it causes. A JPEG is compressed; to resize it, the image library has to decompress every pixel into memory first. A 12 megapixel phone photo that is a few megabytes on disk becomes tens of megabytes once decoded, and that decoded copy stays in memory while the smaller ones are made. To see why the server cannot process the image, we measured it rather than repeat a rule of thumb.<\/p>\n\n\n\n<h3 id=\"aioseo-what-we-measured\" class=\"wp-block-heading\">What We Measured<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">We ran the WordPress 7.1.2 GD image editor, the real class from core rather than a reconstruction, through the exact sequence core follows for an upload: load the original, scale it to 2560 pixels, save it, reload the scaled copy and make the six default sizes. Each photo size ran three times on PHP 8.5, and we recorded the peak memory the whole PHP process used, which is the figure an account memory cap counts. PHP alone started at about 25 MB.<\/p>\n\n\n\n<figure class=\"wp-block-table ah-ladder\"><table><thead><tr><th>Photo<\/th><th>Megapixels<\/th><th>Decoded original<\/th><th>Image data PHP must hold<\/th><th>Measured process peak<\/th><\/tr><\/thead><tbody><tr><td>2560 x 1920<\/td><td>4.9<\/td><td>19 MB<\/td><td>about 31 MB<\/td><td>75 MB<\/td><\/tr><tr><td>4032 x 3024, a common phone camera<\/td><td>12.2<\/td><td>47 MB<\/td><td>about 65 MB<\/td><td>117 to 118 MB<\/td><\/tr><tr><td>6000 x 4000, a common DSLR<\/td><td>24.0<\/td><td>92 MB<\/td><td>about 108 MB<\/td><td>149 to 165 MB<\/td><\/tr><tr><td>8064 x 6048, a 48 MP phone mode<\/td><td>48.8<\/td><td>186 MB<\/td><td>about 205 MB<\/td><td>237 to 258 MB<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\">The AHosting Photo Upload Memory Ladder \u2014 peak memory for one upload through the WordPress 7.1.2 GD resizer, measured on 23 September 2026 at three runs per size. Image data is the decoded original plus the largest copy held beside it, at four bytes per pixel. Imagick was not measured and uses memory differently.<\/figcaption><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The ladder rises with pixel count, not with file size, and the top rung is the one that matters now that phones save 48 megapixel photos. Roughly a quarter of a gigabyte for one upload, before WordPress and your plugins add their own share of the same request.<\/p>\n\n\n\n<h3 id=\"aioseo-why-your-error-log-may-say-nothing\" class=\"wp-block-heading\">Why Your Error Log May Say Nothing<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Here is why the server cannot process the image with nothing in the error log. Whether that image memory counts against PHP\u2019s memory limit depends on how PHP was built. The copy of GD bundled with PHP routes every allocation through PHP\u2019s own allocator, as <a href=\"https:\/\/github.com\/php\/php-src\/blob\/master\/ext\/gd\/libgd\/gdhelpers.h\" target=\"_blank\" rel=\"noopener\">the PHP source defines it<\/a>, so it counts, and running out leaves an <em>Allowed memory size exhausted<\/em> line in the error log. A PHP built against an external GD does not count it, and neither does Imagick, which manages its own memory under <a href=\"https:\/\/imagemagick.org\/resources\/\" target=\"_blank\" rel=\"noopener\">ImageMagick resource limits<\/a> and can spill large images to disk. In those builds PHP never objects. The process can still be stopped by the account memory cap, and then the log is silent.<\/p>\n\n\n\n<h2 id=\"aioseo-which-limit-stops-the-server-from-processing-the-image\" class=\"wp-block-heading\">Which Limit Stops the Server From Processing the Image<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">When the server cannot process the image, one of three separate limits ended the resize, and each leaves a different trace. Finding the right one first saves you from raising a setting that was never the problem, which is the most common wasted fix for this error.<\/p>\n\n\n\n<h3 id=\"aioseo-php-memory-and-the-256-mb-wordpress-already-asks-for\" class=\"wp-block-heading\">PHP Memory, and the 256 MB WordPress Already Asks For<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress raises PHP\u2019s memory limit on its own before any image work, to the value of <code>WP_MAX_MEMORY_LIMIT<\/code>. That constant defaults to 256 MB, or to your PHP limit if that is already higher, and the raise only works where the host lets PHP change the setting at runtime. So raising your PHP limit from 128 MB to 256 MB does nothing for images, a mistake we see often. A PHP limit above 256 MB is adopted automatically, and defining the constant higher in <code>wp-config.php<\/code> is the alternative. Our guide to <a href=\"https:\/\/www.ahosting.net\/blog\/wordpress-memory-limit-errors-2026\/\">WordPress memory limit errors<\/a> covers where each one is set.<\/p>\n\n\n\n<h3 id=\"aioseo-the-account-memory-cap\" class=\"wp-block-heading\">The Account Memory Cap<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">On shared hosting, every PHP process on your account draws from one memory allowance, whatever limit each process was given. A single 48 megapixel upload fits easily. Five of them dropped into the uploader together, a gallery plugin regenerating thumbnails in the background, and a busy front end can add up to more than the account allows, and the process that tips it over is stopped before it can reply, so no retries follow. A request refused for too many simultaneous processes arrives as a 508, which we explained in <a href=\"https:\/\/www.ahosting.net\/blog\/508-resource-limit-reached-wordpress\/\">the guide to 508 resource limit errors<\/a>. The uploader shows this same message for it, even though that photo never reached WordPress at all.<\/p>\n\n\n\n<h3 id=\"aioseo-the-clock\" class=\"wp-block-heading\">The Clock<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Sometimes the server cannot process the image because it ran out of time. Resizing a very large photo on a busy shared processor is slow, and two clocks are running. PHP stops a script that exceeds its maximum execution time, and any proxy in front of the server gives up after its own timeout and returns an error page of its own. The first is a PHP error, so the retries run, and because each retry makes only the copies still missing, a timeout often clears on a later attempt. The second carries no header and is never retried. Our <a href=\"https:\/\/www.ahosting.net\/blog\/wordpress-resource-limit-503-500-error-wordpress-diagnostic-tree\/\">resource limit diagnostic tree<\/a> walks through telling these apart from the account usage graphs.<\/p>\n\n\n\n<h2 id=\"aioseo-how-to-fix-the-server-cannot-process-the-image-in-order\" class=\"wp-block-heading\">How to Fix The Server Cannot Process the Image, in Order<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Work through these in order whenever the server cannot process the image. The early steps take a minute each and tell you which of the later ones you need, so skipping ahead usually means changing a setting that was not the limit.<\/p>\n\n\n\n<style>\n.ahim-tool{background:#0f172a;border-radius:10px;padding:22px;margin:26px 0;color:#fff;font-size:.95rem}\n.ahim-tool h3{color:#fff;margin:0 0 6px;font-size:1.15rem}\n.ahim-tool p.ahim-sub{color:#eef3ff;margin:0 0 18px;font-size:.88rem}\n.ahim-row{display:flex;flex-wrap:wrap;gap:14px;margin-bottom:14px}\n.ahim-f{flex:1 1 180px}\n.ahim-f label{display:block;color:#eef3ff;font-size:.8rem;margin-bottom:5px}\n.ahim-f select{width:100%;padding:8px;border:1px solid #334155;border-radius:6px;background:#1e293b;color:#fff;font-size:.9rem}\n.ahim-btn{background:#2563eb;color:#fff;border:0;border-radius:6px;padding:10px 20px;font-size:.92rem;cursor:pointer;text-decoration:none;display:inline-block}\n.ahim-out{margin-top:18px;padding:16px;background:#1e293b;border-left:4px solid #2563eb;border-radius:6px;display:none}\n.ahim-out.ahim-on{display:block}\n.ahim-num{font-size:1.15rem;font-weight:700;color:#60a5fa;display:block;margin-bottom:8px}\n.ahim-out p{margin:0 0 10px;color:#fff}\n.ahim-out p strong{color:#93c5fd}\n.ahim-note{color:#94a3b8;font-size:.78rem;margin-top:12px}\n<\/style>\n<div class=\"ahim-tool\" data-ahim=\"estimator\">\n  <h3>Photo Upload Memory Check<\/h3>\n  <p class=\"ahim-sub\">Pick the photo size, the image library and the memory WordPress may use for images. This uses the figures we measured running the WordPress 7.1.2 resizer on four photo sizes, so you can see which limit a server-side upload is closest to.<\/p>\n  <div class=\"ahim-row\">\n    <div class=\"ahim-f\">\n      <label for=\"ahim-size\">Photo size<\/label>\n      <select id=\"ahim-size\">\n        <option value=\"s5\">2560 x 1920, about 5 megapixels<\/option>\n        <option value=\"s12\" selected>4032 x 3024, about 12 megapixels<\/option>\n        <option value=\"s24\">6000 x 4000, 24 megapixels<\/option>\n        <option value=\"s48\">8064 x 6048, about 48 megapixels<\/option>\n      <\/select>\n    <\/div>\n    <div class=\"ahim-f\">\n      <label for=\"ahim-lib\">Image library in Site Health<\/label>\n      <select id=\"ahim-lib\">\n        <option value=\"bundled\" selected>GD, version shown as bundled<\/option>\n        <option value=\"outside\">GD external build, or Imagick<\/option>\n      <\/select>\n    <\/div>\n    <div class=\"ahim-f\">\n      <label for=\"ahim-cap\">Memory WordPress may use for images<\/label>\n      <select id=\"ahim-cap\">\n        <option value=\"256\" selected>256 MB, the WordPress default<\/option>\n        <option value=\"512\">512 MB, PHP limit raised<\/option>\n      <\/select>\n    <\/div>\n  <\/div>\n  <button class=\"ahim-btn wp-element-button\" id=\"ahim-go\" type=\"button\">Check this upload<\/button>\n  <div class=\"ahim-out\" id=\"ahim-out\">\n    <span class=\"ahim-num\" id=\"ahim-num\">&#8212;<\/span>\n    <p><strong>Measured peak:<\/strong> <span id=\"ahim-peak\"><\/span><\/p>\n    <p><strong>Which limit sees it:<\/strong> <span id=\"ahim-why\"><\/span><\/p>\n    <p><strong>Do this first:<\/strong> <span id=\"ahim-first\"><\/span><\/p>\n    <p class=\"ahim-note\">Peaks were measured on a workstation with only the WordPress image editor loaded. A real dashboard request also carries WordPress and your plugins, so treat a result marked tight as a likely failure.<\/p>\n  <\/div>\n<\/div>\n<script>\n(function(){\n  document.addEventListener('DOMContentLoaded', function(){\n    var tool = document.querySelector('[data-ahim]');\n    if (!tool) { return; }\n    var mode = tool.getAttribute('data-ahim');\n    if (mode !== 'estimator') { return; }\n    var go = document.getElementById('ahim-go');\n    if (!go) { return; }\n    var out = document.getElementById('ahim-out');\n    if (!out) { return; }\n    var num = document.getElementById('ahim-num');\n    if (!num) { return; }\n    var peak = document.getElementById('ahim-peak');\n    if (!peak) { return; }\n    var why = document.getElementById('ahim-why');\n    if (!why) { return; }\n    var first = document.getElementById('ahim-first');\n    if (!first) { return; }\n    var RSS = {};\n    RSS['s5'] = 75;\n    RSS['s12'] = 118;\n    RSS['s24'] = 165;\n    RSS['s48'] = 258;\n    var PHPMEM = {};\n    PHPMEM['s5'] = 31;\n    PHPMEM['s12'] = 65;\n    PHPMEM['s24'] = 108;\n    PHPMEM['s48'] = 205;\n    go.addEventListener('click', function(){\n      var s = document.getElementById('ahim-size');\n      if (!s) { return; }\n      var l = document.getElementById('ahim-lib');\n      if (!l) { return; }\n      var c = document.getElementById('ahim-cap');\n      if (!c) { return; }\n      var rss = RSS[s.value];\n      var need = PHPMEM[s.value];\n      var cap = parseInt(c.value, 10);\n      var parallel = Math.floor(2048 \/ rss);\n      var label = '';\n      var reason = '';\n      var fix = '';\n      peak.innerHTML = 'about ' + rss + ' MB for the whole PHP process, of which about ' + need + ' MB is image data.';\n      if (l.value === 'bundled') {\n        if (need > cap) {\n          label = 'Likely to fail on PHP memory';\n          fix = 'Resize to 2560 pixels before uploading, or raise the memory for images above ' + need + ' MB.';\n        } else if (need * 4 > cap * 3) {\n          label = 'Tight on PHP memory';\n          fix = 'Raise the memory for images to 512 MB, or resize to 2560 pixels before uploading.';\n        } else {\n          label = 'Fits PHP memory';\n          fix = 'Memory is not your limit for this photo. Check the error log and the clock instead.';\n        }\n        reason = 'Bundled GD counts image data against the ' + cap + ' MB PHP limit, so a failure leaves an allowed memory size line in the error log.';\n      } else {\n        label = 'PHP memory will not object';\n        reason = 'This library allocates outside the PHP limit, so the ' + cap + ' MB setting does not see the image. The account memory cap does: about ' + parallel + ' uploads like this at once would fill a 2 GB account.';\n        fix = 'If uploads fail with nothing in the error log, upload one at a time and check the account resource usage page.';\n      }\n      num.innerHTML = label;\n      why.innerHTML = reason;\n      first.innerHTML = fix;\n      out.className = 'ahim-out ahim-on';\n    });\n  });\n})();\n<\/script>\n\n\n\n<h3 id=\"aioseo-seven-steps-when-the-server-cannot-process-the-image\" class=\"wp-block-heading\">Seven Steps When the Server Cannot Process the Image<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Check the media library before retrying. A photo that stayed without thumbnails means no retries ran, because the process was stopped from outside PHP or something else answered. One that appeared and then vanished was deleted after five failed retries.<\/li>\n\n\n\n<li>Read the PHP error log from the time of the upload. An <em>Allowed memory size<\/em> line means PHP memory. A log with nothing in it points at the account cap, a process limit or a timeout.<\/li>\n\n\n\n<li>Try the same photo from the block editor in Chrome. If it succeeds there and fails in Media, the server was the limit, and in-browser resizing is a working route around it.<\/li>\n\n\n\n<li>Scale the photo to 2560 pixels on its long edge before uploading. WordPress would make that copy anyway, and it removes most of the memory bill.<\/li>\n\n\n\n<li>If you need full-size originals, raise the PHP memory limit above 256 MB, within your plan\u2019s ceiling. WordPress uses any higher PHP limit for images without further changes.<\/li>\n\n\n\n<li>Remove image sizes nobody uses. Every size a theme or plugin registers is another copy made from the decoded original on every upload.<\/li>\n\n\n\n<li>Rebuild any copies that were never made with <a href=\"https:\/\/developer.wordpress.org\/cli\/commands\/media\/regenerate\/\" target=\"_blank\" rel=\"noopener\">the WP-CLI media regenerate command<\/a> and its only-missing option.<\/li>\n<\/ol>\n\n\n\n<h3 id=\"aioseo-fixes-by-what-you-found\" class=\"wp-block-heading\">Fixes by What You Found<\/h3>\n\n\n\n<figure class=\"wp-block-table ah-ladder\"><table><thead><tr><th>What you found<\/th><th>Likely limit<\/th><th>Fix<\/th><th>What not to do<\/th><\/tr><\/thead><tbody><tr><td>Allowed memory size exhausted in the error log<\/td><td>PHP memory for the request<\/td><td>Raise the PHP limit above 256 MB, or pre-scale the photo<\/td><td>Raise the PHP limit to exactly 256 MB, which WordPress already uses<\/td><\/tr><tr><td>Maximum execution time exceeded in the error log<\/td><td>The PHP time limit<\/td><td>Pre-scale the photo, or retry once, since each retry makes only missing copies<\/td><td>Raise the memory limit for a time problem<\/td><\/tr><tr><td>Photo stayed without thumbnails, log silent<\/td><td>Account memory cap, a process limit, or a proxy answered<\/td><td>Upload one photo at a time, then check the resource usage page and proxy logs<\/td><td>Keep retrying the same batch<\/td><\/tr><tr><td>Works in the block editor, fails in Media<\/td><td>Server-side resizing only<\/td><td>Upload from the editor, or pre-scale for Media<\/td><td>Treat the site as broken<\/td><\/tr><tr><td>Fails only on very large originals<\/td><td>The threshold is disabled or raised<\/td><td>Restore the default through the <a href=\"https:\/\/developer.wordpress.org\/reference\/hooks\/big_image_size_threshold\/\" target=\"_blank\" rel=\"noopener\"><code>big_image_size_threshold<\/code> filter<\/a><\/td><td>Disable the threshold on shared hosting<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\">Fixes for the server cannot process the image, by what the first two steps showed. The last column matters as much as the fix: each entry in it either changes nothing or makes the next upload heavier.<\/figcaption><\/figure>\n\n\n\n<h2 id=\"aioseo-when-the-fix-is-more-headroom\" class=\"wp-block-heading\">When the Fix Is More Headroom<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Most sites never need a bigger plan when the server cannot process the image. A photo scaled to 2560 pixels needs less than a third of the memory of a 48 megapixel original, and the block editor can now do the work in the browser. The plan starts to matter when full-resolution originals are part of the job, as they are for photographers and for stores that zoom product images, or when several people upload at once. Before changing anything, confirm which library WordPress is using, as our guide to <a href=\"https:\/\/www.ahosting.net\/blog\/one-or-more-recommended-modules-are-missing\/\">recommended modules that are missing<\/a> explains.<\/p>\n\n\n\n<h3 id=\"aioseo-where-the-work-stops-being-yours\" class=\"wp-block-heading\">Where the Work Stops Being Yours<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">What we take off your hands is the ceiling. Every one of <a href=\"https:\/\/www.ahosting.net\/wordpress-hosting.html\">our WordPress plans<\/a> publishes a PHP memory limit of up to 512 MB, twice what WordPress asks for by default, inside an account allowance of 2, 3 or 4 GB, so a full-size 48 megapixel photo resizes on the server with room to spare once the limit is raised. The account allowance is shared by every site on it, which is why <a href=\"https:\/\/www.ahosting.net\/woocommerce-hosting.html\">the WooCommerce plans<\/a> suit stores uploading large product galleries. For sites that are not WordPress, <a href=\"https:\/\/www.ahosting.net\/web-hosting.html\">our web hosting plans<\/a> carry the same PHP limit, and a site processing images all day belongs on <a href=\"https:\/\/www.ahosting.net\/vps-hosting.html\">a VPS<\/a> with memory of its own.<\/p>\n\n\n\n<h2 id=\"faq-the-server-cannot-process-the-image\" class=\"wp-block-heading\">Frequently Asked Questions About The Server Cannot Process the Image<\/h2>\n\n\n\n<h3 id=\"faq-how-do-i-fix-the-server-cannot-process-the-image-in-wordpress\" class=\"wp-block-heading\">How do I fix the server cannot process the image error in WordPress?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Typically by finding out which limit the resize ran into rather than by retrying the same file. The upload itself usually succeeded, so first check the media library. A photo that stayed without its thumbnails points outside PHP, and one that vanished after a pause was deleted by WordPress after five failed retries. Then read the PHP error log for an allowed memory size line. If one is there, the image needs more PHP memory than the request was allowed. If the log is silent, the process was stopped from outside PHP, by the account memory cap or a timeout. Shrinking the photo to 2560 pixels on its long edge before uploading fixes either case.<\/p>\n\n\n\n<h3 id=\"faq-why-does-the-server-cannot-process-the-image-appear-in-2026\" class=\"wp-block-heading\">Why does WordPress say the server cannot process the image for ordinary photos in 2026?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Specifically because ordinary photos are now very large once decoded. A current phone camera can save a 48 megapixel image, and while the file on disk may be only a few megabytes, the resizer has to unpack every pixel into memory before it can shrink it. In our measurement that single step took a quarter of a gigabyte for a 48 megapixel photo. WordPress then makes up to seven resized copies from it. The error is the message WordPress shows when the server gave up partway through that work.<\/p>\n\n\n\n<h3 id=\"faq-is-the-image-uploaded-when-the-server-cannot-process-the-image\" class=\"wp-block-heading\">Is my photo still uploaded when the server cannot process the image?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In practice it arrives, but it may not stay. WordPress saves the file and creates its media library entry before it starts resizing, and it reports the entry number back to the browser in a response header for exactly this situation. The Media Library uploader then asks the server five more times to finish the resized copies. If every attempt fails, it asks the server to delete the entry and its files, which is why a photo can appear briefly and then vanish. When no retries ran, the original usually remains without its copies.<\/p>\n\n\n\n<h3 id=\"faq-does-ahosting-have-enough-memory-to-stop-the-server-cannot-process-the-image\" class=\"wp-block-heading\">Does AHosting WordPress hosting have enough memory to avoid the server cannot process the image?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">That said, memory is only one of the limits involved, so it is worth being precise. AHosting WordPress plans publish a PHP memory limit of up to 512 MB and account memory of 2, 3 or 4 GB depending on the plan. In our measurement a 48 megapixel photo peaked at about a quarter of a gigabyte during resizing, which fits comfortably inside both once the PHP limit is set above 256 MB. What can still fail is several large uploads at once, because every site on the account shares the same memory cap, and a timeout on a very slow resize.<\/p>\n\n\n\n<h3 id=\"faq-gd-vs-imagick-which-fails-less-on-shared-hosting\" class=\"wp-block-heading\">GD vs Imagick: which image library fails less often with large photo uploads?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">By contrast with the usual advice, neither is simply safer, because they fail in different places. GD, when PHP was built with its bundled copy, counts every decoded pixel against the PHP memory limit, so it fails early and leaves an allowed memory size line in the error log. Imagick allocates outside that limit, so PHP never objects, but the process still counts against the account memory cap and can be stopped there without any PHP error at all. The library that fails less is the one whose limit has more room.<\/p>\n\n\n\n<h3 id=\"faq-block-editor-vs-media-library-why-only-one-shows-the-error\" class=\"wp-block-heading\">Block editor vs Media Library: why does only one of them show this upload error?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Notably WordPress 7.1 changed where resizing happens. On a site served over HTTPS, in a browser that allows it, the block editor now resizes images inside the browser and sends the finished copies to the server, so the server never has to decode the full photo. The Media Library uploader still sends the original and resizes on the server. So the same photo can fail from Media and succeed from the editor. The browser console in the editor prints a line saying which path it used.<\/p>\n\n\n\n<h3 id=\"faq-will-an-ahosting-upgrade-fix-the-server-cannot-process-the-image-2026\" class=\"wp-block-heading\">Will an AHosting plan upgrade fix the server cannot process the image in 2026?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ultimately only if the limit you hit belongs to the plan, and the error log tells you whether it does. A larger plan raises the account memory cap and the number of processes that can run at once, which helps when several large uploads or a busy site share the account. It does not help when the PHP memory limit is set below what one photo needs, because that is a setting you can raise yourself within the published ceiling. Check that setting first, and upgrade only when the account cap is the proven limit.<\/p>\n\n\n\n<h3 id=\"faq-can-i-raise-the-memory-limit-myself-for-large-photo-uploads\" class=\"wp-block-heading\">Can I raise the memory limit myself so large photo uploads stop failing?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Indeed you usually can, and it helps to know what WordPress already does. Before image work it raises the limit to the value of the WP_MAX_MEMORY_LIMIT constant, which is 256 MB unless your PHP limit is higher, so raising the PHP limit from 128 to 256 changes nothing for images. Set the PHP limit above 256 MB and WordPress adopts the higher figure on its own. Defining the constant in wp-config.php is the other route, where PHP may raise its own limit. Neither can exceed the account cap.<\/p>\n\n\n\n<h3 id=\"faq-how-do-i-check-which-image-library-my-ahosting-account-uses\" class=\"wp-block-heading\">How do I check which image library my AHosting WordPress site is using?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Fortunately WordPress will tell you without any code. Open Tools, then Site Health, then the Info tab, and expand Media Handling. The Active editor line names the library WordPress picked, the GD version line shows whether GD is the bundled build, and when Imagick is loaded its resource limits are listed too. On an AHosting account the extension list for each PHP version is in Select PHP Version in cPanel, so turning Imagick on or off for the version you run is a checkbox.<\/p>\n\n\n\n<h3 id=\"faq-does-the-server-cannot-process-the-image-affect-seo-in-2026\" class=\"wp-block-heading\">Does the server cannot process the image error affect SEO or page speed in 2026?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Interestingly the error itself affects nothing visitors or crawlers see, because it only happens in the dashboard. What it affects is what you publish next. A photo that uploads without its resized copies, or one that is re-uploaded at full size to get around the error, can end up served to phones at many times the size they need, and oversized images are among the most common causes of a slow largest contentful paint. So fix the resize, not the symptom, and check that the resized copies exist.<\/p>\n\n\n\n<script>\n(function(){\n  document.addEventListener('DOMContentLoaded', function(){\n    var allH3s = document.querySelectorAll('h3.wp-block-heading');\n    var inFaq = false;\n    for (var i = 0; i < allH3s.length; i++) {\n      var h3 = allH3s[i];\n      var prev = h3.previousElementSibling;\n      if (prev) {\n        if (prev.tagName === 'H2') {\n          var prevId = prev.getAttribute('id');\n          if (prevId) {\n            if (prevId.indexOf('faq-') === 0) {\n              inFaq = true;\n            } else {\n              inFaq = false;\n            }\n          }\n        }\n      }\n      if (inFaq) {\n        initToggle(h3);\n      }\n    }\n    function initToggle(h3) {\n      var answer = h3.nextElementSibling;\n      if (!answer) { return; }\n      if (answer.tagName !== 'P') { return; }\n      answer.style.display = 'none';\n      h3.style.cursor = 'pointer';\n      h3.setAttribute('tabindex', '0');\n      h3.setAttribute('aria-expanded', 'false');\n      h3.addEventListener('click', function(){\n        toggleOne(h3, answer);\n      });\n      h3.addEventListener('keydown', function(ev){\n        if (ev.key === 'Enter') { toggleOne(h3, answer); }\n        if (ev.key === ' ') { ev.preventDefault(); toggleOne(h3, answer); }\n      });\n    }\n    function toggleOne(h3, answer) {\n      var open = h3.getAttribute('aria-expanded') === 'true';\n      if (open) {\n        answer.style.display = 'none';\n        h3.setAttribute('aria-expanded', 'false');\n      } else {\n        answer.style.display = 'block';\n        h3.setAttribute('aria-expanded', 'true');\n      }\n    }\n  });\n})();\n<\/script>\n","protected":false},"excerpt":{"rendered":"<p>TL;DR When WordPress says the server cannot process the image, the upload almost always worked. What failed is the resizing that follows, which unpacks every pixel of the photo into memory before making up to seven smaller copies. We measured that at about a quarter of a gigabyte for a 48 megapixel phone photo. Since [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":1329,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[8],"tags":[60,111,108,170,270,110,296,113],"class_list":["post-1325","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-cloudlinux","tag-lve","tag-php","tag-php-memory-limit","tag-resource-limits","tag-shared-hosting","tag-the-server-cannot-process-the-image","tag-wordpress-errors"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"A Header That Carries the Media Entry Number Just before WordPress starts resizing, it sends a response header named X-WP-Upload-Attachment-ID carrying the number of the media entry it has just created. The core source comments explain why: it lets the browser resume creating the resized copies after a fatal PHP error. If resizing then crashes\" \/>\n\t<meta name=\"robots\" content=\"max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n\t<meta name=\"author\" content=\"Matt Chrust\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"AHosting Blog | WordPress Hosting Tips &amp; Guides\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"The Server Cannot Process the Image: What WordPress Is Telling You | AHosting Blog\" \/>\n\t\t<meta property=\"og:description\" content=\"A Header That Carries the Media Entry Number Just before WordPress starts resizing, it sends a response header named X-WP-Upload-Attachment-ID carrying the number of the media entry it has just created. The core source comments explain why: it lets the browser resume creating the resized copies after a fatal PHP error. If resizing then crashes\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/www.ahosting.net\/blog\/wp-content\/uploads\/2026\/09\/the-server-cannot-process-the-image-ahosting.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/www.ahosting.net\/blog\/wp-content\/uploads\/2026\/09\/the-server-cannot-process-the-image-ahosting.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t\t<meta property=\"og:image:height\" content=\"675\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2026-09-24T16:20:18+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2026-09-25T16:45:00+00:00\" \/>\n\t\t<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n\t\t<meta name=\"twitter:site\" content=\"@ahostingdotnet\" \/>\n\t\t<meta name=\"twitter:title\" content=\"The Server Cannot Process the Image: What WordPress Is Telling You | AHosting Blog\" \/>\n\t\t<meta name=\"twitter:description\" content=\"A Header That Carries the Media Entry Number Just before WordPress starts resizing, it sends a response header named X-WP-Upload-Attachment-ID carrying the number of the media entry it has just created. The core source comments explain why: it lets the browser resume creating the resized copies after a fatal PHP error. If resizing then crashes\" \/>\n\t\t<meta name=\"twitter:creator\" content=\"@ahostingdotnet\" \/>\n\t\t<meta name=\"twitter:image\" content=\"https:\/\/www.ahosting.net\/blog\/wp-content\/uploads\/2026\/09\/the-server-cannot-process-the-image-ahosting.jpg\" \/>\n\t\t<script type=\"application\/ld+json\" class=\"aioseo-schema\">\n\t\t\t{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"BlogPosting\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#article\",\"name\":\"The Server Cannot Process the Image: What WordPress Is Telling You | AHosting Blog\",\"headline\":\"The Server Cannot Process the Image: What WordPress Is Telling You\",\"author\":{\"@type\":\"Person\",\"name\":\"Matt Chrust\",\"url\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/author\\\/matt-chrust\\\/\"},\"publisher\":{\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/#organization\"},\"image\":{\"@type\":\"ImageObject\",\"url\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/the-server-cannot-process-the-image-ahosting.jpg\",\"width\":1200,\"height\":675,\"caption\":\"Listen: when WordPress says the server cannot process the image, the upload usually worked and the resizing did not, and what is left in the media library tells you which limit it hit. By Matt Chrust, Director of Business Development, AHosting.\"},\"datePublished\":\"2026-09-24T16:20:18+00:00\",\"dateModified\":\"2026-09-25T16:45:00+00:00\",\"inLanguage\":\"en-US\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#webpage\"},\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#webpage\"},\"articleSection\":\"WordPress, CloudLinux, LVE, PHP, php memory limit, resource limits, Shared Hosting, the server cannot process the image, WordPress errors\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#breadcrumblist\",\"itemListElement\":[{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/#listItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/\",\"nextItem\":{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/category\\\/wordpress\\\/#listItem\",\"name\":\"WordPress\"}},{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/category\\\/wordpress\\\/#listItem\",\"position\":2,\"name\":\"WordPress\",\"item\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/category\\\/wordpress\\\/\",\"nextItem\":{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#listItem\",\"name\":\"The Server Cannot Process the Image: What WordPress Is Telling You\"},\"previousItem\":{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/#listItem\",\"name\":\"Home\"}},{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#listItem\",\"position\":3,\"name\":\"The Server Cannot Process the Image: What WordPress Is Telling You\",\"previousItem\":{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/category\\\/wordpress\\\/#listItem\",\"name\":\"WordPress\"},\"item\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/\"}]},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/#organization\",\"name\":\"AHosting\",\"description\":\"WordPress Hosting Tips & Guides\",\"url\":\"https:\\\/\\\/www.ahosting.net\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"url\":\"https:\\\/\\\/www.ahosting.net\\\/assets\\\/img\\\/ahosting-logo.svg\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#organizationLogo\"},\"image\":{\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#organizationLogo\"},\"sameAs\":[\"https:\\\/\\\/x.com\\\/ahostingdotnet\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/author\\\/matt-chrust\\\/#author\",\"url\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/author\\\/matt-chrust\\\/\",\"name\":\"Matt Chrust\",\"image\":{\"@type\":\"ImageObject\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#authorImage\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/795895edac1c44589f6c7f5e6bb79df405fbbaac15817bdd387ec57da61731ec?s=96&d=mm&r=g\",\"width\":96,\"height\":96,\"caption\":\"Matt Chrust\"}},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#webpage\",\"url\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/\",\"name\":\"The Server Cannot Process the Image: What WordPress Is Telling You | AHosting Blog\",\"description\":\"A Header That Carries the Media Entry Number Just before WordPress starts resizing, it sends a response header named X-WP-Upload-Attachment-ID carrying the number of the media entry it has just created. The core source comments explain why: it lets the browser resume creating the resized copies after a fatal PHP error. If resizing then crashes\",\"inLanguage\":\"en-US\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/#website\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#breadcrumblist\"},\"author\":{\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/author\\\/matt-chrust\\\/#author\"},\"creator\":{\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/author\\\/matt-chrust\\\/#author\"},\"image\":{\"@type\":\"ImageObject\",\"url\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/the-server-cannot-process-the-image-ahosting.jpg\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#mainImage\",\"width\":1200,\"height\":675,\"caption\":\"Listen: when WordPress says the server cannot process the image, the upload usually worked and the resizing did not, and what is left in the media library tells you which limit it hit. By Matt Chrust, Director of Business Development, AHosting.\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/blog\\\/the-server-cannot-process-the-image\\\/#mainImage\"},\"datePublished\":\"2026-09-24T16:20:18+00:00\",\"dateModified\":\"2026-09-25T16:45:00+00:00\"},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/#website\",\"url\":\"https:\\\/\\\/www.ahosting.net\\\/\",\"name\":\"AHosting\",\"description\":\"WordPress Hosting Tips & Guides\",\"inLanguage\":\"en-US\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.ahosting.net\\\/#organization\"}}]}\n\t\t<\/script>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"The Server Cannot Process the Image: What WordPress Is Telling You | AHosting Blog","description":"A Header That Carries the Media Entry Number Just before WordPress starts resizing, it sends a response header named X-WP-Upload-Attachment-ID carrying the number of the media entry it has just created. The core source comments explain why: it lets the browser resume creating the resized copies after a fatal PHP error. If resizing then crashes","canonical_url":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/","robots":"max-snippet:-1, max-image-preview:large, max-video-preview:-1","keywords":"","webmasterTools":{"miscellaneous":""},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"BlogPosting","@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#article","name":"The Server Cannot Process the Image: What WordPress Is Telling You | AHosting Blog","headline":"The Server Cannot Process the Image: What WordPress Is Telling You","author":{"@type":"Person","name":"Matt Chrust","url":"https:\/\/www.ahosting.net\/blog\/author\/matt-chrust\/"},"publisher":{"@id":"https:\/\/www.ahosting.net\/#organization"},"image":{"@type":"ImageObject","url":"https:\/\/www.ahosting.net\/blog\/wp-content\/uploads\/2026\/09\/the-server-cannot-process-the-image-ahosting.jpg","width":1200,"height":675,"caption":"Listen: when WordPress says the server cannot process the image, the upload usually worked and the resizing did not, and what is left in the media library tells you which limit it hit. By Matt Chrust, Director of Business Development, AHosting."},"datePublished":"2026-09-24T16:20:18+00:00","dateModified":"2026-09-25T16:45:00+00:00","inLanguage":"en-US","mainEntityOfPage":{"@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#webpage"},"isPartOf":{"@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#webpage"},"articleSection":"WordPress, CloudLinux, LVE, PHP, php memory limit, resource limits, Shared Hosting, the server cannot process the image, WordPress errors"},{"@type":"BreadcrumbList","@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#breadcrumblist","itemListElement":[{"@type":"ListItem","@id":"https:\/\/www.ahosting.net\/blog\/#listItem","position":1,"name":"Home","item":"https:\/\/www.ahosting.net\/blog\/","nextItem":{"@type":"ListItem","@id":"https:\/\/www.ahosting.net\/blog\/category\/wordpress\/#listItem","name":"WordPress"}},{"@type":"ListItem","@id":"https:\/\/www.ahosting.net\/blog\/category\/wordpress\/#listItem","position":2,"name":"WordPress","item":"https:\/\/www.ahosting.net\/blog\/category\/wordpress\/","nextItem":{"@type":"ListItem","@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#listItem","name":"The Server Cannot Process the Image: What WordPress Is Telling You"},"previousItem":{"@type":"ListItem","@id":"https:\/\/www.ahosting.net\/blog\/#listItem","name":"Home"}},{"@type":"ListItem","@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#listItem","position":3,"name":"The Server Cannot Process the Image: What WordPress Is Telling You","previousItem":{"@type":"ListItem","@id":"https:\/\/www.ahosting.net\/blog\/category\/wordpress\/#listItem","name":"WordPress"},"item":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/"}]},{"@type":"Organization","@id":"https:\/\/www.ahosting.net\/#organization","name":"AHosting","description":"WordPress Hosting Tips & Guides","url":"https:\/\/www.ahosting.net\/","logo":{"@type":"ImageObject","url":"https:\/\/www.ahosting.net\/assets\/img\/ahosting-logo.svg","@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#organizationLogo"},"image":{"@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#organizationLogo"},"sameAs":["https:\/\/x.com\/ahostingdotnet"]},{"@type":"Person","@id":"https:\/\/www.ahosting.net\/blog\/author\/matt-chrust\/#author","url":"https:\/\/www.ahosting.net\/blog\/author\/matt-chrust\/","name":"Matt Chrust","image":{"@type":"ImageObject","@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#authorImage","url":"https:\/\/secure.gravatar.com\/avatar\/795895edac1c44589f6c7f5e6bb79df405fbbaac15817bdd387ec57da61731ec?s=96&d=mm&r=g","width":96,"height":96,"caption":"Matt Chrust"}},{"@type":"WebPage","@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#webpage","url":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/","name":"The Server Cannot Process the Image: What WordPress Is Telling You | AHosting Blog","description":"A Header That Carries the Media Entry Number Just before WordPress starts resizing, it sends a response header named X-WP-Upload-Attachment-ID carrying the number of the media entry it has just created. The core source comments explain why: it lets the browser resume creating the resized copies after a fatal PHP error. If resizing then crashes","inLanguage":"en-US","isPartOf":{"@id":"https:\/\/www.ahosting.net\/blog\/#website"},"breadcrumb":{"@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#breadcrumblist"},"author":{"@id":"https:\/\/www.ahosting.net\/blog\/author\/matt-chrust\/#author"},"creator":{"@id":"https:\/\/www.ahosting.net\/blog\/author\/matt-chrust\/#author"},"image":{"@type":"ImageObject","url":"https:\/\/www.ahosting.net\/blog\/wp-content\/uploads\/2026\/09\/the-server-cannot-process-the-image-ahosting.jpg","@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#mainImage","width":1200,"height":675,"caption":"Listen: when WordPress says the server cannot process the image, the upload usually worked and the resizing did not, and what is left in the media library tells you which limit it hit. By Matt Chrust, Director of Business Development, AHosting."},"primaryImageOfPage":{"@id":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/#mainImage"},"datePublished":"2026-09-24T16:20:18+00:00","dateModified":"2026-09-25T16:45:00+00:00"},{"@type":"WebSite","@id":"https:\/\/www.ahosting.net\/#website","url":"https:\/\/www.ahosting.net\/","name":"AHosting","description":"WordPress Hosting Tips & Guides","inLanguage":"en-US","publisher":{"@id":"https:\/\/www.ahosting.net\/#organization"}}]},"og:locale":"en_US","og:site_name":"AHosting Blog | WordPress Hosting Tips &amp; Guides","og:type":"article","og:title":"The Server Cannot Process the Image: What WordPress Is Telling You | AHosting Blog","og:description":"A Header That Carries the Media Entry Number Just before WordPress starts resizing, it sends a response header named X-WP-Upload-Attachment-ID carrying the number of the media entry it has just created. The core source comments explain why: it lets the browser resume creating the resized copies after a fatal PHP error. If resizing then crashes","og:url":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/","og:image":"https:\/\/www.ahosting.net\/blog\/wp-content\/uploads\/2026\/09\/the-server-cannot-process-the-image-ahosting.jpg","og:image:secure_url":"https:\/\/www.ahosting.net\/blog\/wp-content\/uploads\/2026\/09\/the-server-cannot-process-the-image-ahosting.jpg","og:image:width":1200,"og:image:height":675,"article:published_time":"2026-09-24T16:20:18+00:00","article:modified_time":"2026-09-25T16:45:00+00:00","twitter:card":"summary_large_image","twitter:site":"@ahostingdotnet","twitter:title":"The Server Cannot Process the Image: What WordPress Is Telling You | AHosting Blog","twitter:description":"A Header That Carries the Media Entry Number Just before WordPress starts resizing, it sends a response header named X-WP-Upload-Attachment-ID carrying the number of the media entry it has just created. The core source comments explain why: it lets the browser resume creating the resized copies after a fatal PHP error. If resizing then crashes","twitter:creator":"@ahostingdotnet","twitter:image":"https:\/\/www.ahosting.net\/blog\/wp-content\/uploads\/2026\/09\/the-server-cannot-process-the-image-ahosting.jpg"},"aioseo_meta_data":{"post_id":"1325","title":null,"description":null,"keywords":null,"keyphrases":{"focus":[],"additional":[]},"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"Article","isEnabled":true},"graphs":[]},"schema_type":"default","schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"breadcrumb_settings":null,"limit_modified_date":false,"ai":null,"created":"2026-09-24 16:16:25","updated":"2026-09-25 16:47:14","seo_analyzer_scan_date":null,"focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"aioseo_breadcrumb":"<div class=\"aioseo-breadcrumbs\"><span class=\"aioseo-breadcrumb\">\n\t\t\t<a href=\"https:\/\/www.ahosting.net\/blog\/\" title=\"Home\">Home<\/a>\n\t\t<\/span><span class=\"aioseo-breadcrumb-separator\">\u00bb<\/span><span class=\"aioseo-breadcrumb\">\n\t\t\t<a href=\"https:\/\/www.ahosting.net\/blog\/category\/wordpress\/\" title=\"WordPress\">WordPress<\/a>\n\t\t<\/span><span class=\"aioseo-breadcrumb-separator\">\u00bb<\/span><span class=\"aioseo-breadcrumb\">\n\t\t\tThe Server Cannot Process the Image: What WordPress Is Telling You\n\t\t<\/span><\/div>","aioseo_breadcrumb_json":[{"label":"Home","link":"https:\/\/www.ahosting.net\/blog\/"},{"label":"WordPress","link":"https:\/\/www.ahosting.net\/blog\/category\/wordpress\/"},{"label":"The Server Cannot Process the Image: What WordPress Is Telling You","link":"https:\/\/www.ahosting.net\/blog\/the-server-cannot-process-the-image\/"}],"_links":{"self":[{"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/posts\/1325","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/comments?post=1325"}],"version-history":[{"count":3,"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/posts\/1325\/revisions"}],"predecessor-version":[{"id":1333,"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/posts\/1325\/revisions\/1333"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/media\/1329"}],"wp:attachment":[{"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/media?parent=1325"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/categories?post=1325"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ahosting.net\/blog\/wp-json\/wp\/v2\/tags?post=1325"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}