{"id":3062,"date":"2026-07-16T20:11:49","date_gmt":"2026-07-16T20:11:49","guid":{"rendered":"https:\/\/www.serverspan.com\/blog\/"},"modified":"2026-07-16T20:11:55","modified_gmt":"2026-07-16T20:11:55","slug":"wordpress-image-upload-shared-hosting-gd-imagemagick-limits","status":"publish","type":"post","link":"https:\/\/www.serverspan.com\/en\/blog\/wordpress-image-upload-shared-hosting-gd-imagemagick-limits\/","title":{"rendered":"WordPress Image Upload on Shared Hosting: Fixes"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\"><strong>A WordPress image upload on shared hosting usually fails at one of two stages: receiving the file or processing it after the upload.<\/strong> Errors shown before the progress bar completes normally point to file-size, request-body, temporary-directory or security limits. Errors shown after the file reaches 100% usually mean GD or ImageMagick could not decode the image, create responsive sizes or write the results before a memory, time, disk or account-level limit was reached. Check the stage first. Raising every PHP value blindly can hide the useful evidence without correcting the real restriction.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Written by the ServerSpan Technical Team<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Determine whether the upload or the image processing failed<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The first diagnostic question is whether the original file reached <code>wp-content\/uploads<\/code>. WordPress performs several operations after receiving it. The application creates an attachment record, reads the image, applies orientation information, scales very large originals and generates every registered image size.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If the original appears in the Media Library after refreshing the page but its thumbnail is blank or missing, the HTTP upload probably succeeded. The failure occurred during post-processing.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Visible symptom<\/th><th>Most likely stage<\/th><th>First check<\/th><\/tr><\/thead><tbody><tr><td>The file is rejected immediately because it is too large<\/td><td>PHP or web-server upload limit<\/td><td>Compare <code>upload_max_filesize<\/code>, <code>post_max_size<\/code> and any HTTP request-body limit<\/td><\/tr><tr><td>The progress reaches 100%, then WordPress says the server cannot process the image<\/td><td>Image decoding or sub-size generation<\/td><td>Check the active editor, memory, timeouts and PHP error log<\/td><\/tr><tr><td>The original appears, but thumbnail and medium sizes are missing<\/td><td>Post-processing stopped after the file was saved<\/td><td>Inspect attachment metadata and regenerate only the missing sizes after fixing the cause<\/td><\/tr><tr><td>WordPress reports that it cannot create a directory or move the file<\/td><td>Filesystem path or permissions<\/td><td>Check the current uploads directory and whether PHP can write to it<\/td><\/tr><tr><td>The browser reports HTTP 413<\/td><td>Web server or proxy rejected the request before WordPress<\/td><td>Ask the host to inspect the request-body limit<\/td><\/tr><tr><td>The request returns HTTP 406<\/td><td>Security filtering<\/td><td>Inspect the ModSecurity audit log and the matched rule<\/td><\/tr><tr><td>The request intermittently returns 500 or 503 during busy periods<\/td><td>PHP worker, RAM, process or execution ceiling<\/td><td>Correlate the timestamp with hosting resource and PHP logs<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">An HTTP 406 failure belongs to a different troubleshooting path. The ServerSpan guide about <a href=\"https:\/\/www.serverspan.com\/en\/blog\/why-some-actions-on-your-wp-blog-are-triggering-modsec-406\/\">WordPress actions triggering ModSecurity 406<\/a> explains how to identify the matched rule without disabling the web application firewall globally.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">A small JPEG file can require hundreds of megabytes while processing<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The compressed file size shown on your computer is not the amount of memory required by GD or ImageMagick. A JPEG might occupy 5 MB on disk but expand into tens or hundreds of megabytes when decoded into pixels.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A useful lower-bound calculation for one four-byte pixel buffer is:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Pixel-buffer memory<\/strong> = width \u00d7 height \u00d7 4 bytes.<\/p>\n<\/blockquote>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Image dimensions<\/th><th>Pixels<\/th><th>One four-byte buffer<\/th><th>Operational meaning<\/th><\/tr><\/thead><tbody><tr><td>4,000 \u00d7 3,000<\/td><td>12 megapixels<\/td><td>About 45.8 MiB<\/td><td>The source buffer alone can use a significant part of a small PHP memory allowance<\/td><\/tr><tr><td>6,000 \u00d7 4,000<\/td><td>24 megapixels<\/td><td>About 91.6 MiB<\/td><td>Source and destination buffers can exceed 128 MiB before WordPress and plugins are counted<\/td><\/tr><tr><td>8,000 \u00d7 6,000<\/td><td>48 megapixels<\/td><td>About 183.1 MiB<\/td><td>One decoded buffer can already exceed many shared-hosting PHP limits<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The calculation covers only one simplified pixel buffer. Resizing may require the original image, a destination buffer, metadata, library overhead and the memory already used by WordPress, the theme and plugins. PNG files with transparency and high-resolution camera images can therefore fail despite having a modest compressed file size.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress uses 2560 pixels as its default threshold for scaling a large image. This explains the suggested maximum shown in the generic error message. It does not mean every 2,561-pixel image must fail or that every smaller image must work.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Resize the longest edge to 2560 pixels or less when the website does not need the original camera resolution. If a 1200 \u00d7 800 JPEG also fails, further resizing is unlikely to be the real repair.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">WordPress normally tries ImageMagick before GD<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress selects an available implementation of its image-editor interface. The default order is ImageMagick through the PHP Imagick extension, followed by the GD library.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Open <strong>Tools \u2192 Site Health \u2192 Info \u2192 Media handling<\/strong>. Record the following values before changing the site:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Active editor.<\/li>\n\n\n\n<li>ImageMagick and Imagick versions, when available.<\/li>\n\n\n\n<li>GD version and supported formats.<\/li>\n\n\n\n<li>Maximum uploaded file size and maximum POST size.<\/li>\n\n\n\n<li>Whether file uploads are enabled.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">GD and ImageMagick can fail for different reasons. GD holds decoded image data in memory controlled directly by PHP. This makes PHP memory exhaustion a common failure mode for high-resolution images.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">ImageMagick can move its pixel cache from memory to mapped storage or disk, but it also has its own security and resource policies. A restrictive ImageMagick configuration can reject an operation even when PHP reports unused memory.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Do not permanently force GD because one upload worked during a test. First confirm that the same image consistently fails under Imagick and succeeds under GD. The hosting provider should then inspect the Imagick extension, ImageMagick policy, temporary path and relevant logs.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Each PHP limit controls a different part of the request<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Increasing <code>upload_max_filesize<\/code> does not increase the RAM available for thumbnail generation. The PHP directives are separate limits applied at different stages.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>PHP directive<\/th><th>What it limits<\/th><th>Typical failure<\/th><th>Decision rule<\/th><\/tr><\/thead><tbody><tr><td><code>upload_max_filesize<\/code><\/td><td>One uploaded file<\/td><td>The file is rejected before processing<\/td><td>Set it above the largest file you intentionally accept<\/td><\/tr><tr><td><code>post_max_size<\/code><\/td><td>The complete HTTP POST body<\/td><td>The request arrives without the expected file data<\/td><td>Keep it higher than <code>upload_max_filesize<\/code><\/td><\/tr><tr><td><code>memory_limit<\/code><\/td><td>Memory allocated by the PHP script<\/td><td><code>Allowed memory size exhausted<\/code> in the PHP log<\/td><td>Size it for decoded pixels, WordPress and active plugins<\/td><\/tr><tr><td><code>max_input_time<\/code><\/td><td>Time allowed to receive and parse request input<\/td><td>Uploads from slow connections stop before completion<\/td><td>Increase it only when the transfer itself exceeds the limit<\/td><\/tr><tr><td><code>max_execution_time<\/code><\/td><td>PHP script execution time<\/td><td>Processing stops while creating image sizes<\/td><td>Increase it when logs or timing prove that image processing is exceeding it<\/td><\/tr><tr><td><code>upload_tmp_dir<\/code><\/td><td>Temporary location used while receiving files<\/td><td>Missing temporary folder or failed temporary write<\/td><td>The path must exist, be permitted and have free space<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Site Health shows the values used by the web request and is therefore more useful than a random <code>php.ini<\/code> file found through SSH. Shared servers can run several PHP versions and separate configurations for Apache, PHP-FPM and the command line.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">With WP-CLI access, the following read-only command prints the values used by its PHP process:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>wp eval '\n$keys = array(\n    \"memory_limit\",\n    \"upload_max_filesize\",\n    \"post_max_size\",\n    \"max_execution_time\",\n    \"max_input_time\",\n    \"upload_tmp_dir\"\n);\n\nforeach ( $keys as $key ) {\n    echo $key . \"=\" . ini_get( $key ) . PHP_EOL;\n}\n\necho \"imagick=\" . ( extension_loaded( \"imagick\" ) ? \"yes\" : \"no\" ) . PHP_EOL;\necho \"gd=\" . ( extension_loaded( \"gd\" ) ? \"yes\" : \"no\" ) . PHP_EOL;\n'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Good output contains values consistent with Site Health and confirms at least one image library. Different values do not prove that WordPress is wrong. They usually mean WP-CLI loaded another PHP binary or configuration file. Use <code>wp cli info<\/code> to identify the CLI PHP executable and loaded <code>php.ini<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Adding <code>WP_MEMORY_LIMIT<\/code> to <code>wp-config.php<\/code> is only a request from WordPress. It cannot override a hard account limit or a PHP setting that the hosting environment refuses to change.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">ImageMagick has limits outside PHP<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">ImageMagick can limit image width, height, pixel-cache area, heap memory, mapped memory, disk cache, thread count and elapsed processing time. Shared-hosting customers normally cannot edit the server-wide <code>policy.xml<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">With shell access, inspect the active policy without changing it:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>magick identify -list policy\nmagick identify -list resource<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Some servers use ImageMagick 6 and expose <code>identify<\/code> without the <code>magick<\/code> prefix:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>identify -list policy\nidentify -list resource<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Look for unexpectedly small values under <code>memory<\/code>, <code>map<\/code>, <code>disk<\/code>, <code>width<\/code>, <code>height<\/code> or <code>time<\/code>. A memory limit does not always stop the operation immediately because ImageMagick can fall back to mapped storage or disk. Processing becomes much slower and may then hit the disk or time limit.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Send the output and the failed image dimensions to the hosting provider. Do not ask for all limits to be removed. Resource policies protect a shared server from malformed images and simultaneous processing spikes. The correct fix is a limit that supports ordinary website images without allowing one account to consume the entire host.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Disk space, inodes and permissions can stop thumbnail creation<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">An account can show available gigabytes and still fail because it has exhausted inodes, temporary storage or the ability to write into the current month\u2019s uploads directory.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Check <strong>Tools \u2192 Site Health \u2192 Info \u2192 Directories and Sizes<\/strong> and <strong>Filesystem Permissions<\/strong>. WordPress should be able to write to the uploads directory.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">With shell access, use read-only checks:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>df -h\ndf -ih\n\nfind wp-content\/uploads -maxdepth 2 -type d ! -writable -print\n\nfind wp-content\/uploads -maxdepth 2 -type f | tail -n 20<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><code>df -h<\/code> reports filesystem capacity. <code>df -ih<\/code> reports inode use. A filesystem at 100% in either result cannot create additional thumbnails or temporary files.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The directory test should return no WordPress upload directories. Output means the shell user considers those directories non-writable, although the PHP user may differ. Do not apply recursive <code>chmod 777<\/code> or change ownership blindly. Ask the provider to confirm the correct account user and permission model.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The PHP error log should decide the next change<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Repeat one failed upload while recording the exact timestamp, filename, dimensions and format. Then inspect the account\u2019s PHP error log through the hosting control panel.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Log text<\/th><th>Meaning<\/th><th>Next action<\/th><\/tr><\/thead><tbody><tr><td><code>Allowed memory size exhausted<\/code><\/td><td>The PHP process reached its memory limit<\/td><td>Reduce dimensions, remove unnecessary processing or request a higher effective memory allowance<\/td><\/tr><tr><td><code>Maximum execution time exceeded<\/code><\/td><td>PHP processing lasted too long<\/td><td>Check image dimensions, generated sizes and editor performance before increasing the timeout<\/td><\/tr><tr><td><code>ImagickException<\/code> or <code>cache resources exhausted<\/code><\/td><td>ImageMagick rejected the operation or exhausted a resource policy<\/td><td>Inspect ImageMagick policy, temporary storage and format support<\/td><\/tr><tr><td><code>No space left on device<\/code><\/td><td>Disk or temporary storage is full<\/td><td>Check account quota, host filesystem and temporary path<\/td><\/tr><tr><td><code>Permission denied<\/code><\/td><td>PHP cannot read the source or write a generated file<\/td><td>Correct ownership and permissions according to the hosting account model<\/td><\/tr><tr><td>No PHP error, but HTTP 413 or 406 appears in the browser<\/td><td>The request was rejected before PHP completed it<\/td><td>Inspect web-server, proxy or security logs<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">If the site displays a WordPress critical error during the same operation, follow the logging and recovery process in the ServerSpan guide to <a href=\"https:\/\/www.serverspan.com\/en\/blog\/how-to-fix-the-wordpress-critical-error-complete-recovery-guide-for-any-website\/\">fixing WordPress critical errors<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Use a controlled image test instead of changing every setting<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A useful test set contains the same image exported in several controlled variants:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The original image.<\/li>\n\n\n\n<li>The same image resized to a 2560-pixel longest edge.<\/li>\n\n\n\n<li>A 1200-pixel JPEG exported without unusual metadata.<\/li>\n\n\n\n<li>A known-good JPEG or PNG that uploaded successfully in the past.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">If only the original fails, the server is probably reaching a dimension-related processing limit. If every new image fails, inspect the editor, permissions, temporary path and service health. If one file fails regardless of size while other images work, the file may be malformed or use a format feature unsupported by the installed library.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Disable plugins only on a staging copy or during a controlled maintenance window. Image optimization, WebP conversion, watermarking, security and e-commerce plugins can register additional processing callbacks or image sizes. A plugin conflict is proven when the same file succeeds after a specific plugin is disabled and fails again after it is restored.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Repair incomplete attachments after correcting the server<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">When the original image exists but its responsive sizes are missing, fix the server-side cause before regenerating anything. Otherwise the repair job will repeat the same failure across many files.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">List the image sizes registered by the current theme and plugins:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>wp media image-size<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Regenerate the missing sizes for one known attachment first:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>wp media regenerate 123 --only-missing<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">A successful result reports that the thumbnails were regenerated for attachment ID 123. An error gives you a repeatable CLI test without the browser uploader.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Create a current backup before a site-wide regeneration. Large media libraries can consume substantial CPU and I\/O, so process them in controlled batches or ask the hosting provider to schedule the job. Do not regenerate thousands of images during the site\u2019s busiest period.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Shared hosting is adequate when normal web images process reliably<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A WordPress website does not require a VPS merely because it uses photographs. Shared hosting remains appropriate when normal JPEG, PNG and WebP uploads complete reliably, the active editor is maintained, resource limits support the site\u2019s registered sizes and the provider can investigate account-level errors.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A VPS becomes reasonable when the workload includes repeated bulk imports, very large source images, many custom thumbnail sizes or an image-processing pipeline that requires control over ImageMagick policy and background jobs. The decision should be based on repeated workload requirements, not one corrupted image.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The ServerSpan comparison of <a href=\"https:\/\/www.serverspan.com\/en\/blog\/shared-hosting-vs-vps-which-one-do-you-actually-need-in-2026\/\">shared hosting and VPS hosting<\/a> explains the control and administration tradeoff. Moving to an unmanaged VPS gives you more configuration access, but also makes PHP, ImageMagick, security, backups and monitoring your responsibility.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If your current provider cannot supply a working WordPress image editor, effective PHP values or useful error logs, ServerSpan\u2019s <a href=\"https:\/\/www.serverspan.com\/en\/webhosting\">DirectAdmin web hosting<\/a> provides the commercial handoff for a managed shared-hosting environment. Supply one failed image, its dimensions, the exact timestamp and the Site Health media report when requesting support.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The practical diagnostic rule is simple. If the original file never reaches the uploads directory, inspect request and filesystem limits. If the original exists but its image sizes do not, inspect GD or ImageMagick, decoded-pixel memory, processing time and write access. Change only the limit identified by the evidence.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A WordPress image upload on shared hosting usually fails at one of two stages: receiving the file or processing it after the upload. Errors shown before the progress bar completes normally point to file-size, request-body, temporary-directory or security limits. Errors shown after the file reaches 100% usually mean GD or ImageMagick could not decode the [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3063,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[17372,17373,17364,17363,17359,17360,17355,17380,17362,17368,17354,17376,17369,17358,17375,17365,17352,17351,17357,17356,17367,17378,17379,17366,17353,17371,17361,17370,17374,17377],"class_list":["post-3062","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-hosting","tag-gd-vs-imagick-wordpress","tag-imagemagick-resource-limits","tag-max_execution_time-wordpress","tag-max_input_time-wordpress","tag-php-memory-limit-wordpress","tag-post_max_size-wordpress","tag-post-processing-of-the-image-failed","tag-shared-hosting-for-wordpress-images","tag-upload_max_filesize-wordpress","tag-wordpress-2560-pixel-error","tag-wordpress-gd-library","tag-wordpress-http-413-upload","tag-wordpress-image-dimensions-memory","tag-wordpress-image-memory-limit","tag-wordpress-image-processing-error","tag-wordpress-image-timeout","tag-wordpress-image-upload-failed","tag-wordpress-image-upload-shared-hosting","tag-wordpress-imagemagick","tag-wordpress-imagick-error","tag-wordpress-media-library-upload-error","tag-wordpress-missing-image-sizes","tag-wordpress-modsecurity-406-upload","tag-wordpress-responsive-image-sizes-error","tag-wordpress-server-cannot-process-image","tag-wordpress-shared-hosting-limits","tag-wordpress-thumbnail-generation-failed","tag-wordpress-upload-directory-permissions","tag-wordpress-uploads-folder-not-writable","tag-wp-cli-regenerate-thumbnails"],"_links":{"self":[{"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3062","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3062"}],"version-history":[{"count":1,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3062\/revisions"}],"predecessor-version":[{"id":3064,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3062\/revisions\/3064"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/media\/3063"}],"wp:attachment":[{"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3062"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3062"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3062"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}