Sometimes when I upload a picture (either with flash or browser uploader), I get a message like (this was with a 1.46MB jpg):

Fatal error: Out of memory (allocated 69206016) (tried to allocate 4000 bytes) in /home/ab64489/public_html/wp-includes/media.php on line 254

I am on a shared host, but the max upload size is 64MB. I've tried uploading other files (I made a zip of some random files, with the archive totaling ~58.1MB, and it uploads and crunches with no problem, so it's not the file size). It also seems that the upload works fine, but when it tries to crunch, then it encounters the error.

I've seen similar problems here and on other sites with no real solutions.

What could be the cause of this issue?

  • If the problem occurs every time you try to upload a specific picture, then check the resolution of the image. Try reducing the resolution and see if the problem persist.
    – Nathan
    Commented Mar 3, 2012 at 23:11

3 Answers 3


This isn't a Wordpress problem. There's no telling on a shared environment what the culprit might be. You probably don't have access to your php.ini config, nor do we know how many websites your hosting company has jammed on your server.

The very nature of a shared server is that each client shares the resources of that one server. If one website is using massive amounts of resources while you're trying to upload your image, that would certainly affect it.

The only real fix to this is getting onto a more controllable environment. I gave up on shared hosting a long time ago and went with a cloud server from Rackspace. I am in complete control and I don't have to worry about other memory hogs on the same box.

You can also look at your code and identify blocks that use significant memory by printing out memory_get_usage() before and after. You might need to debug in WordPress core, or in plugins. I typically start pretty wide and start zooming into problematic areas of code. You'll find the memory leak this way if it's in your code.

  • How can you be that sure? I have a vps and this problem occurs to me too. Commented Jul 2, 2022 at 16:23
  • 1
    @SteveMoretz This could be a server issue, or it could be a memory leak in code. I updated the answer for you. Commented Jul 5, 2022 at 16:46
  • That function was a good mention thanks! Commented Jul 5, 2022 at 17:28

My solution (in wordpress 3.3.1) was to do the image compression myself, then add a single entry to the metadata table in the DB.

For the image compression, I noted the other correctly compressed files were all compressed to three consistent sizes: 150x150, Mx300, and Nx1024, where M and N would maintain the ratio of the original image.

In the metadata table, there was already an entry for my newly created post. Sort by post_id and then look for the entry with your post_id and meta_key = _wp_attached_file to make sure yours is there.

My corresponding row has meta_value = 2012/04/get_in_shape.png.

Now the fun part! Find a row (from a post which had its image correctly compressed) with meta_key = _wp_attachment_metadata and use its value of meta_value as a template for your new row.

In your new row, the values should be

`meta_id`  (null)  as it's an AUTOINCREMENT field
`post_id`  (your post id)
`meta_key` _wp_attachment_metadata
`meta_value`  (as below)

The following is a serialize()ed string with the data that worked for me for meta_value. It will not work for you without tweaks. If you can do all the above, you can certainly do the tweaks as well.

a:6:{s:5:"width";s:4:"3321";s:6:"height";s:4:"4153";s:14:"hwstring_small";s:22:"height='96' width='67'";s:4:"file";s:24:"2012/03/get_in_shape.png";s:5:"sizes";a:3:{s:9:"thumbnail";a:3:{s:4:"file";s:24:"get_in_shape-150x150.png";s:5:"width";s:3:"150";s:6:"height";s:3:"150";}s:6:"medium";a:3:{s:4:"file";s:24:"get_in_shape-240x300.png";s:5:"width";s:3:"212";s:6:"height";s:3:"300";}s:5:"large";a:3:{s:4:"file";s:25:"get_in_shape-819x1024.png";s:5:"width";s:3:"724";s:6:"height";s:4:"1024";}}s:10:"image_meta";a:10:{s:8:"aperture";s:1:"0";s:6:"credit";s:0:"";s:6:"camera";s:0:"";s:7:"caption";s:0:"";s:17:"created_timestamp";s:1:"0";s:9:"copyright";s:0:"";s:12:"focal_length";s:1:"0";s:3:"iso";s:1:"0";s:13:"shutter_speed";s:1:"0";s:5:"title";s:0:"";}}

See the path looking thing 2012/04/get_in_shape.png? That's the path to your file (with wp-content as its understood prefix). Note it's preceded by s:24 which is the string length of the value. Change the path to match your file, then change the 24 to match the length of the path you used.

Do that for each of the file sizes, save the new record, and you're golden.

DO NOT TRY THIS if you have little/no idea how to do it. Just sayin' there is a cheaper(*) method than moving to a new host.

(*) if learning all this in uni is considered cheap.


For me it was really a memory issue (in the code), I was using a plugin called blurhash that did some stuff on the images, so make sure to disable all your plugins and you might find the problem, and then push a fix or something or fork it.

For instance in my case the blurhash was running multiple times on the image so I added a simple cache mechanism and my problem was gone.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.