"Error HTTP" al subir imágenes en WordPress: el árbol de decisión que sí encuentra la causa

“Error HTTP” no es una causa. Es el subidor de medios reconociendo que envió tu archivo al servidor y recibió una respuesta que no pudo interpretar como éxito, y hay al menos seis fallos sin relación entre sí que producen ese mismo mensaje. Adivinar entre ellos es la razón por la que hay gente que pasa una tarde subiendo upload_max_filesize en una web cuyo problema real es una regla de firewall.

La salida más rápida es una sola observación que separa las seis causas en dos grupos, y después una comprobación por rama.

Primero: lee la respuesta real

Abre las herramientas de desarrollo de tu navegador, ve a la pestaña Red y vuelve a subir el archivo. Fíjate en la petición a async-upload.php. Lo que llegue de vuelta es tu diagnóstico.

Lo que ves	Qué significa	Ve a
403 o 406, con cuerpo HTML	El firewall o mod_security rechazó la petición	Rama A
500, respuesta vacía o cuerpo truncado	PHP se cayó o se quedó sin memoria a mitad del proceso	Rama B
413	El cuerpo de la petición superó un límite del servidor	Rama C
200, pero el cuerpo no es JSON limpio	Un plugin o el tema imprimió texto antes de la respuesta	Rama D
La petición nunca termina o expira	Límite de tiempo de ejecución, normalmente con archivos grandes	Rama B

Ese único vistazo descarta por ti la mayor parte de los consejos que circulan por internet. Si no puedes llegar a las herramientas del navegador, activa antes el registro en wp-config.php:

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

Reproduce la subida y lee wp-content/debug.log. Una línea de error fatal te nombra la rama directamente. Si la línea es densa, pégala en el descodificador de registros de error: asocia las firmas de error fatal más comunes con lo que se rompió de verdad.

Rama A — una regla de firewall o de mod_security

Un 403 con una página HTML en el cuerpo significa que la petición nunca llegó a WordPress. Algo situado delante (mod_security, Cloudflare, Wordfence, Sucuri o el propio conjunto de reglas de tu hosting) decidió que ese POST parecía malicioso.

La comprobación: desactiva temporalmente cualquier plugin de seguridad y vuelve a subir el archivo. Si eso no cambia nada, la regla vive a nivel de servidor y necesitas que tu hosting revise el registro de auditoría de mod_security a la hora exacta de la subida fallida. Ellos pueden poner en la lista blanca el ID concreto de la regla.

Sé sincero contigo mismo sobre los consejos que vas a encontrar aquí. Los fragmentos que te dicen que pegues esto en .htaccess:

SecFilterEngine Off
SecFilterScanPOST Off

apuntan a mod_security 1.x, que está prácticamente extinto. En un servidor moderno esas directivas o no hacen nada o lanzan un 500 que empeora la situación. El mod_security actual usa SecRuleEngine, y de todas formas la mayoría de los alojamientos gestionados bloquean que se sobrescriba por directorio. Pregunta a tu hosting; no pegues código a ciegas.

Rama B — límites de memoria o de ejecución de PHP

Es la rama más habitual y la que tiene la señal más clara: es intermitente. El mismo archivo sube al tercer intento, o una foto de 2 MB falla mientras un PDF de 6 MB pasa sin problema. Los límites fijos de configuración fallan igual siempre. Los fallos de memoria no, porque la cantidad disponible depende de qué más esté haciendo el servidor en ese momento.

Por qué ocurre justo con las imágenes: WordPress no se limita a guardar el archivo, lo descomprime a píxeles en bruto para generar cada tamaño intermedio (medium_large, todo lo registrado con add_image_size, woocommerce_thumbnail si tienes tienda, más una copia -scaled si la imagen supera el big_image_size_threshold). Un JPEG de 12 megapíxeles ocupa unos pocos MB en disco y unos 48 MB en memoria, antes del búfer de redimensionado. Un límite de 128 MB se evapora enseguida.

Súbelo en wp-config.php, por encima de la línea de “stop editing”:

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

El coste real: WP_MEMORY_LIMIT no puede superar lo que PHP permite. Si tu hosting limita memory_limit a 128M, esa constante es decorativa. Comprueba el valor verdadero en Herramientas → Salud del sitio → Información → Servidor, no en lo que tú escribiste. Si el techo lo pone el propio PHP, solo el hosting puede moverlo.

Rama C — límites de tamaño de archivo y de petición

Mira los números reales en Herramientas → Salud del sitio → Información → Gestión de medios. Hay dos ajustes que importan y la gente solo cambia uno:

• upload_max_filesize: el límite de un archivo individual.
• post_max_size: el límite del cuerpo completo de la petición.

Si el POST entero supera post_max_size, PHP descarta la petición antes de que WordPress ejecute una sola línea de código. No existe nada que devolver, así que el subidor recibe una respuesta imposible de interpretar y dice “Error HTTP”. post_max_size siempre debería ser cómodamente mayor que upload_max_filesize.

Un matiz que conviene conocer: cuando un archivo supera únicamente upload_max_filesize, el subidor suele detectarlo en el navegador y avisa de que el archivo excede el tamaño máximo de subida, que es un mensaje mucho más claro. Así que un “Error HTTP” a secas apunta más a menudo a post_max_size o a la Rama B que al ajuste que todo el mundo sube primero.

Dónde cambiarlos depende de tu stack. En Apache con mod_php, .htaccess funciona:

php_value upload_max_filesize 64M
php_value post_max_size 128M

En PHP-FPM, LiteSpeed o NGINX, que es la mayoría del hosting moderno, esas líneas no hacen nada y pueden lanzar un 500. Usa en su lugar el panel de ajustes PHP de tu hosting o un archivo .user.ini. NGINX además impone su propio client_max_body_size, que solo puede subir el hosting.

Rama D — la librería de edición de imágenes (Imagick frente a GD)

WordPress prefiere ImageMagick cuando la extensión de PHP está presente y recurre a GD si no lo está. En alojamiento compartido, ImageMagick es a menudo el problema: su archivo de configuración de políticas restringe memoria, disco y área por operación, y cuando un redimensionado supera uno de esos límites el proceso muere sin dar un mensaje útil. Normalmente lo verás con imágenes grandes mientras las pequeñas funcionan, lo cual parece la Rama B pero no lo es.

Fuerza GD para comprobar la teoría:

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

Ponlo en functions.php o en un pequeño mu-plugin, reintenta la subida y quítalo si no cambia nada.

La contrapartida honesta: GD no es estrictamente mejor. Mantiene el mapa de bits completo sin comprimir en la memoria de PHP, así que con archivos muy grandes puede chocar con memory_limit donde ImageMagick, que trabaja en parte fuera de la asignación de PHP, habría salido adelante. El cambio puede sustituir un fallo por otro. Trátalo primero como diagnóstico y después como solución.

Rama E — permisos del directorio de subidas

Raro en alojamiento gestionado, habitual justo después de una migración o de un traslado manual de servidor. Si wp-content/uploads no tiene permisos de escritura para el usuario del servidor web, o si una subcarpeta de año/mes recién creada heredó el propietario equivocado, la escritura falla.

ls -ld wp-content/uploads
ls -ld wp-content/uploads/2026/07

Los directorios deberían estar normalmente en 755 y pertenecer al usuario con el que se ejecuta PHP. No pongas 777 porque lo diga un foro: eso arregla el síntoma haciendo la carpeta escribible por cualquier cuenta del servidor, lo que en alojamiento compartido es una exposición real.

Rama F — el nombre del archivo

Es la comprobación más barata de la lista, así que hazla pronto aunque sea la menos probable. Renombra el archivo con letras minúsculas, números y guiones, sin tildes, apóstrofos, ampersands, # ni caracteres no latinos, y vuelve a subirlo. Los caracteres especiales activan de vez en cuando una regla de seguridad o fallan en un sistema de archivos con codificación distinta. Diez segundos para descartarlo.

Lo que no debes hacer

No empieces desactivando todos los plugins. Es molesto y solo pone a prueba la Rama A y la Rama D. La respuesta de red te dice más en cinco segundos.

No añadas una línea de handler cualquiera en .htaccess. Los fragmentos que circulan con directivas SetHandler o AddHandler asumen la configuración PHP de un hosting concreto. En el stack equivocado tumban la web entera con un 500.

No des por resuelto un “al reintentar funcionó”. El éxito intermitente es la firma de la Rama B, y volverá en cuanto el servidor esté cargado o alguien suba algo más pesado.

¿Sigues atascado?

Si la respuesta es un 200 limpio con JSON válido y la subida sigue fallando, la rotura está después de que el archivo aterrice: normalmente un plugin enganchado a la cadena de procesamiento del adjunto que lanza un error fatal, o un plugin optimizador que hace su propia petición a un servicio externo y expira. Activa WP_DEBUG_LOG, reproduce el fallo y pasa el error fatal resultante por el descodificador de registros de error para ver qué archivo y qué hook son los verdaderos responsables.