Error HTTP en WordPress al subir imágenes: cómo arreglarlo

En pocas palabras: El error HTTP al subir imágenes en WordPress es un aviso genérico: la subida falló o se cortó al procesar la imagen. Las causas típicas son memory_limit insuficiente, conflicto con Imagick o permisos en wp-content/uploads. Probá primero subir memory_limit y pasar de Imagick a GD.

El error HTTP de WordPress al subir imágenes aparece cuando falla la subida o el procesamiento de la imagen, por memoria PHP insuficiente, un conflicto con Imagick o permisos mal puestos en wp-content/uploads. Los dos primeros ajustes a probar: subir memory_limit y pasar de Imagick a GD.

Un error HTTP en la biblioteca de medios de WordPress es un aviso genérico que muestra el cargador de archivos cuando la subida termina con una respuesta de error del servidor o se corta mientras se procesa una imagen. No indica la causa: puede venir de PHP (memoria, tiempo de ejecución, límites de tamaño), del editor de imágenes (Imagick o GD), de permisos o de un plugin.

¿Cuál es el tamaño máximo de subida de archivos en WordPress y cómo verlo?

El tamaño máximo de subida lo define PHP en tu servidor, no WordPress. Lo ves en Medios > Añadir nuevo, debajo de la zona de arrastre, o en Herramientas > Salud del sitio > Info, en la sección de medios. El valor efectivo es el menor entre upload_max_filesize y post_max_size.

Ponele que subís un PDF de 20 MB y WordPress lo rechaza de entrada. Eso es un límite de tamaño. Ahora, si subís una foto de 3 MB y te aparece un aviso tan «descriptivo» como Error HTTP, el peso del archivo probablemente no sea el problema. Conviene separar los tres mensajes que más se confunden:

• «Excede el tamaño máximo de subida»: el archivo pesa más que el límite de PHP. Se arregla en la sección de upload_max_filesize.
• «Error HTTP»: la subida llegó, pero algo falló al recibirla o procesarla. Hay que leer el log.
• «El archivo subido no pudo moverse a wp-content/uploads/…»: WordPress no puede escribir en esa carpeta. Casi siempre son permisos, propietario o disco lleno.

¿Por qué aparece el error HTTP de WordPress al subir una imagen?

El error HTTP aparece porque el servidor corta o rechaza la subida y WordPress no recibe un detalle útil que mostrar. Las causas habituales son memoria PHP agotada al generar los tamaños de imagen, tiempo de ejecución excedido, Imagick, permisos de uploads, un plugin o el tema. El log dice cuál es la tuya.

Síntomas

Arrastrás la imagen, la barra de progreso avanza (a veces hasta el final) y en el recuadro del archivo aparece este mensaje. En instalaciones en inglés se ve como «HTTP error»:

Error HTTP

Puede pasar que el original llegue a la carpeta uploads y falten los tamaños intermedios. Mirá por FTP si quedó algo.

Complementá con mantener WordPress siempre actualizado.

Causa

Subís la foto del catálogo, el navegador arranca la barra de progreso, el archivo llega entero al servidor, PHP empieza a generar los tamaños intermedios, se queda sin memoria a mitad de camino, el proceso muere sin dejar nada claro en pantalla y vos ves un Error HTTP que no te cuenta qué pasó. Ese es el mecanismo típico.

El handbook de administración avanzada de WordPress lista varios errores que terminan igual: «Allowed memory size exhausted», «Maximum execution time exceeded» y los timeouts en hosting compartido. También documenta un caso menos obvio: pantalla en blanco al subir imágenes junto con 404 en los enlaces permanentes, por mod_rewrite desactivado en Apache. Según esa página, es frecuente en Multisite, en hosting compartido y después de una migración.

Solución paso a paso

1. Agregá esto en wp-config.php, arriba de la línea que dice «That’s all, stop editing»:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

2. Reproducí el error subiendo la misma imagen.
3. Abrí wp-content/debug.log por FTP o desde el administrador de archivos. Esa es la ruta que menciona el handbook para los errores críticos.
4. Si el log está vacío, buscá el error log de PHP en el panel de tu hosting.
5. Cruzá lo que dice con esta guía: «Allowed memory size» va a la sección de memoria, «Maximum execution time» a la de tiempos, «Unable to create directory» a la de permisos, y cualquier mención de Imagick a la sección de Imagick y GD.
6. Cuando termines, poné WP_DEBUG en false.

Cómo prevenirlo

Dejá el debug apagado en producción y borrá el debug.log cuando termines, porque ese archivo puede ser accesible por URL (el tema de seguridad lo desarrollan en seguridadenwordpress.com).

¿Cómo aumentar upload_max_filesize y post_max_size en WordPress?

Para subir el límite de subida tenés que cambiar upload_max_filesize y post_max_size en php.ini, en .user.ini, en .htaccess (solo con Apache y mod_php) o en el selector de PHP de tu panel. Siempre dejá post_max_size por encima de upload_max_filesize, como indica la documentación de PHP.

Síntomas

WordPress avisa que el archivo excede el tamaño máximo de subida del sitio, o la barra llega al final y el servidor responde con un 413 (típico cuando el servidor web es Nginx):

413 Request Entity Too Large

Causa

Los valores por defecto de PHP son bajos para un sitio con fotos. En la página de directivas del core de PHP figuran estos, y tu hosting puede haberlos cambiado:

Directiva	Qué controla	Default de PHP	Valor de ejemplo
upload_max_filesize	Peso máximo de cada archivo	2M	64M
post_max_size	Tamaño máximo de todo el envío	8M	72M
memory_limit	Memoria por script	128M	256M
max_execution_time	Segundos máximos por script	30	120

Los valores de ejemplo son una sugerencia mía, no una recomendación oficial. Ajustalos a lo que realmente subís.

Solución paso a paso

1. Anotá el límite actual de Medios > Añadir nuevo.
2. Si tu hosting tiene selector de PHP, cambiá los valores ahí. Es lo más seguro.
3. Si podés editar php.ini (o .user.ini, cuando PHP corre con FPM), agregá:

upload_max_filesize = 64M
post_max_size = 72M
memory_limit = 256M
max_execution_time = 120

4. Con Apache y mod_php, podés usar .htaccess:

php_value upload_max_filesize 64M
php_value post_max_size 72M
php_value memory_limit 256M
php_value max_execution_time 120

5. Si el sitio da error 500 después de editar .htaccess, sacá esas líneas: el handbook identifica un .htaccess dañado como causa más probable de un Internal Server Error, y con PHP en FPM esas directivas no se aceptan.
6. Si usás Nginx, sumá client_max_body_size 64M; en el bloque server y recargá el servicio. Este paso no sale de las fuentes oficiales de WordPress; es configuración estándar de Nginx.
7. Recargá Medios > Añadir nuevo y verificá que el máximo cambió.

Ojo: poner ini_set en functions.php no sirve para estas dos directivas. Son del tipo PHP_INI_PERDIR según la tabla de php.net, o sea que solo se cambian en php.ini, .user.ini o .htaccess. Tema relacionado: probar cambios en un entorno staging.

Cómo prevenirlo

Después de cada migración o cambio de versión de PHP, revisá el máximo de subida: el valor nuevo no siempre hereda tu configuración.

¿Cómo aumentar el límite de memoria de PHP en WordPress?

Para subir el límite de memoria agregá define( 'WP_MEMORY_LIMIT', '256M' ); en wp-config.php y, si el hosting lo permite, memory_limit en php.ini. El handbook de WordPress recomienda ambos caminos para «Allowed memory size exhausted», y max_execution_time en php.ini para los timeouts.

Síntomas

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate ... bytes)
Maximum execution time of 30 seconds exceeded

El primer número (134217728 bytes son 128M) corresponde al default de PHP. Si ves otro, tu hosting usa un límite distinto.

Causa

Un JPG de 3 MB no ocupa 3 MB en memoria. Hagamos la cuenta con una foto de 4000 x 3000 px: son 12 millones de píxeles y, a 4 bytes por píxel una vez descomprimida, unos 48 MB solo para tener la imagen abierta, antes de generar cada tamaño intermedio. Es una cuenta aproximada, no una medición. ¿Por qué falla en una foto y no en otra del mismo peso? Porque cuenta la cantidad de píxeles, no los megas del archivo.

Solución paso a paso

1. En wp-config.php, arriba de la línea «That’s all, stop editing»:

define( 'WP_MEMORY_LIMIT', '256M' );

2. Subí memory_limit en php.ini o en el panel, y mantenelo por encima de post_max_size.
3. Si el log muestra «Maximum execution time», subí max_execution_time (la tabla de arriba usa 120 como ejemplo).
4. En hosting compartido, el handbook aclara que quizá tengas que pedirle el aumento al proveedor.

Cómo prevenirlo

Redimensioná antes de subir. Menos píxeles, menos memoria.

¿Cómo cambiar Imagick por GD si sigue el error HTTP?

Para usar GD en lugar de Imagick, agregá un filtro wp_image_editors que devuelva solo WP_Image_Editor_GD. Según la referencia oficial del hook, el filtro existe desde WordPress 3.5.0 y su lista por defecto es Imagick primero, GD después.

Síntomas

El Error HTTP se repite con cualquier imagen, incluso chica, y el log menciona Imagick, o el log no dice nada y el error cambia de una subida a otra (spoiler: eso suele ser consumo de recursos del lado del servidor).

Causa

WordPress intenta primero con Imagick. Si esa librería está mal compilada, limitada por el servidor o consume más recursos de los que tu plan permite, la subida muere. Qué tan frecuente es esto, no lo sé: ninguna de las fuentes lo cuantifica. Ya lo cubrimos antes en migrar tu sitio con Duplicator.

Solución paso a paso

1. Verificá en Herramientas > Salud del sitio > Info qué editor usa tu sitio.
2. Agregá el filtro en un plugin de snippets o en functions.php del tema hijo:

add_filter( 'wp_image_editors', function ( $editors ) {
 return array( 'WP_Image_Editor_GD' );
} );

3. Probá otra subida y revisá que las miniaturas se vean bien.
4. Para revertir, borrá el snippet. WordPress vuelve a probar Imagick y después GD.

Hay una alternativa que circula en la comunidad (no está en la documentación oficial): limitar los hilos de Imagick con putenv( 'MAGICK_THREAD_LIMIT=1' ); en wp-config.php. Tomalo con pinzas y probalo antes de cambiar de librería.

Cómo prevenirlo

Si cambiás de servidor, repetí la prueba de subida antes de apuntar el dominio.

¿Qué permisos debe tener la carpeta wp-content/uploads?

La carpeta wp-content/uploads y sus subcarpetas suelen llevar permisos 755, y los archivos 644, con el usuario del servidor web como propietario o con acceso de escritura. Si WordPress no puede crear la carpeta del mes, la subida falla.

Síntomas

Unable to create directory wp-content/uploads/2026/10. Is its parent directory writable by the server?
The uploaded file could not be moved to wp-content/uploads/2026/10.

Causa

Propietario equivocado después de una migración, permisos restrictivos, una ruta de uploads personalizada rota (opción upload_path o constante UPLOADS), disco o cuota llenos, o caracteres raros en el nombre del archivo.

Solución paso a paso

1. Si tenés SSH, aplicá los permisos de forma recursiva:

find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;

2. Revisá el propietario con ls -l wp-content. Debe coincidir con el usuario bajo el que corre PHP.
3. Si tu sitio usa una ruta personalizada, confirmá que existe y es escribible.
4. Chequeá el espacio libre y la cuota del plan.
5. Renombrá el archivo sin tildes, espacios ni símbolos y probá de nuevo.

Cómo prevenirlo

Después de mover un sitio, reaplicá permisos y propietario antes de abrirlo al público.

¿Cómo descartar plugins, tema e imágenes demasiado grandes?

Para descartar conflictos, desactivá los plugins de a uno (seguridad, optimización de imágenes, constructores), probá con un tema por defecto y subí una imagen más chica. Si falla solo con fotos enormes, el problema es el tamaño en píxeles, no un plugin. Cobertura relacionada: otros errores habituales con Patchstack.

Síntomas

El error aparece solo después de instalar o actualizar algo, o solo con fotos directas de cámara o celular. Te puede servir nuestra cobertura de corregir enlaces rotos en tu sitio.

Causa

El handbook de WordPress lista los conflictos entre plugins y temas como causa de errores críticos y timeouts. Con las fotos pasa otra cosa: según el anuncio de WordPress 5.3 en Make WordPress, una foto de un celular moderno pesa fácil más de 5 MB, y desde esa versión cualquier imagen con alto o ancho mayor a 2560 px se reduce al subirla. El original queda guardado y se accede con wp_get_original_image_path().

Solución paso a paso

1. Desactivá todos los plugins (el handbook explica cómo renombrando la carpeta plugins por FTP si no entrás al admin) y probá la subida.
2. Reactivalos de a uno hasta encontrar el que rompe.
3. Activá un tema por defecto para descartar el tuyo.
4. Si usás Apache y ves 404 en los enlaces permanentes, entrá a Ajustes > Enlaces permanentes y guardá sin cambiar nada para regenerar .htaccess.
5. Probá otro navegador y, antes de subir, redimensioná o comprimí la foto.
6. Si no querés el escalado de WordPress 5.3, desactivalo con este filtro:

add_filter( 'big_image_size_threshold', '__return_false' );

Eso sí: sin el escalado, tu servidor procesa archivos más grandes, y el error de memoria vuelve. Mirá también configurar HTTPS y HSTS correctamente.

Cómo prevenirlo

Probá las actualizaciones de plugins en un entorno de staging cuando el sitio sube imágenes todos los días.

¿Qué solución corresponde a cada síntoma?

Síntoma	Causa probable	Solución rápida	Versiones afectadas
Error HTTP y el log dice «Allowed memory size»	Memoria PHP agotada	WP_MEMORY_LIMIT y memory_limit	Cualquiera
Error HTTP con cualquier imagen, log con Imagick	Editor de imágenes	Filtro wp_image_editors con GD	Filtro disponible desde 3.5.0
«Excede el tamaño máximo de subida»	upload_max_filesize o post_max_size bajos	Subirlos en php.ini, .user.ini o panel	Cualquiera
413 Request Entity Too Large	Límite del servidor web	client_max_body_size (Nginx)	Cualquiera
«Maximum execution time of 30 seconds exceeded»	Tiempo de ejecución	max_execution_time	Cualquiera
«Unable to create directory» o «could not be moved»	Permisos, propietario o disco	755/644 y revisar cuota	Cualquiera
Pantalla en blanco al subir y 404 en permalinks	mod_rewrite desactivado	Guardar enlaces permanentes	Cualquiera
Falla solo con fotos enormes	Memoria por píxeles	Redimensionar antes de subir	El escalado a 2560 px rige desde 5.3

Qué está confirmado y qué queda pendiente

No corrí pruebas ni mediciones para esta nota: lo que sigue sale de la documentación oficial y de cómo funciona PHP.

• Confirmado en la documentación: el filtro wp_image_editors (desde 3.5.0, Imagick y GD por defecto), el umbral de 2560 px y el filtro big_image_size_threshold (WordPress 5.3), el uso de wp-content/debug.log, y los defaults de PHP de la tabla.
• Recomendación de la comunidad, sin respaldo oficial: limitar MAGICK_THREAD_LIMIT.
• Pendiente en tu caso: cuál de las causas es la tuya. Las fuentes no dan estadísticas de frecuencia, así que el log es el único árbitro.

Cuándo contactar soporte

Escribile al soporte de tu hosting si no podés editar php.ini ni .user.ini, si el servidor corta la subida con 413 o 500 y no tenés acceso a su configuración, o si el log muestra errores de disco, cuota o módulos de PHP faltantes.

Antes de abrir el ticket, juntá estos datos:

• Versiones: de WordPress, de PHP y del tema.
• Valores actuales: los de Salud del sitio > Info (límite de subida y editor de imágenes).
• El mensaje exacto: las líneas del debug.log o del error log de PHP, con fecha y hora de la prueba.
• Qué descartaste: plugins desactivados, tema por defecto, prueba con GD.

Si sospechás un bug de WordPress, preguntá en los foros oficiales de soporte.

Preguntas Frecuentes

¿Cuál es la diferencia entre upload_max_filesize y post_max_size?

upload_max_filesize limita el peso de cada archivo, y post_max_size limita el tamaño total de la petición, que incluye todos los archivos y campos del formulario. Los defaults de PHP son 2M y 8M, y post_max_size debe ser mayor que upload_max_filesize.

¿Qué permisos tiene que tener wp-content/uploads?

Carpetas 755 y archivos 644, con el servidor web con permiso de escritura. Si sale «Unable to create directory», revisá primero el propietario y después la cuota de disco.

¿Cómo cambio Imagick por GD en WordPress?

Agregá un filtro wp_image_editors que devuelva array( ‘WP_Image_Editor_GD’ ). Para volver a Imagick, borrá el filtro: WordPress prueba por defecto Imagick y después GD.

¿Por qué me aparece error HTTP aunque la imagen pese poco?

El peso del archivo no es lo que consume memoria: cuenta la cantidad de píxeles, porque la imagen se descomprime al procesarla. Una foto de 4000 x 3000 px ocupa unos 48 MB en memoria según una cuenta aproximada, aunque el JPG sea liviano. Otras causas posibles son Imagick, permisos y plugins.

¿Dónde veo el límite real de subida de mi sitio?

En Medios > Añadir nuevo, debajo de la zona de arrastre, y en Herramientas > Salud del sitio > Info. Ese número es el efectivo, así que ya contempla los dos límites de PHP.

Conclusión

Una de las causas habituales del error HTTP en WordPress es la memoria PHP insuficiente al procesar la imagen. Subir WP_MEMORY_LIMIT y memory_limit, y asegurarte de que post_max_size supere a upload_max_filesize, resuelve buena parte de los casos que vi documentados, aunque ninguna fuente publica un porcentaje. Si no alcanzó, probá GD en lugar de Imagick, revisá permisos 755/644 en uploads y desactivá plugins de a uno. Y si nada funciona, llevá el debug.log y los valores de Salud del sitio al soporte de tu hosting.

Fuentes

• Common WordPress errors – Handbook de administración avanzada de WordPress
• Handling of big images en WordPress 5.3 – Make WordPress Core
• wp_image_editors – Referencia del hook en Developer.WordPress.org
• Directivas de php.ini del core – Manual de PHP
• Tutorial de la comunidad sobre el error HTTP al subir imágenes – WPBeginner