Cómo aumentar el tamaño máximo de archivo de subida en WordPress

Arrastras un vídeo de 60MB a la biblioteca de medios de WordPress, esperas unos segundos y te devuelve uno de tres mensajes de error: "El archivo subido excede la directiva upload_max_filesize de php.ini", "413 Request Entity Too Large", o simplemente "Error HTTP" sin más explicación. La solución es casi siempre subir el tamaño máximo de carga, pero como con la mayoría de temas de límites en WordPress, no hay solo un límite. Hay cuatro, viven en sitios distintos y gana el más bajo. Esta guía repasa qué límite causa qué mensaje de error y cómo subir cada uno en los distintos setups de hosting.

¿Qué límite es responsable de cada error?

Cuatro ajustes separados pueden bloquear una subida. Saber cuál te ha pillado ahorra mucho ensayo y error.

• PHP upload_max_filesize. El techo duro al tamaño de un único archivo subido. El valor por defecto en la mayoría de hosts está entre 2M y 64M. Si tu archivo lo supera, WordPress muestra el mensaje explícito "El archivo subido excede la directiva upload_max_filesize".
• PHP post_max_size. El tamaño máximo de toda la petición POST, incluyendo el archivo y cualquier otro campo de formulario. Tiene que ser al menos tan grande como upload_max_filesize; si no, la subida falla en silencio antes de que WordPress siquiera la vea. Por defecto suele estar entre 8M y 64M.
• PHP max_execution_time y max_input_time. Límites de tiempo en segundos. Una subida grande sobre una conexión lenta puede tocar el límite de tiempo antes de que el archivo termine de transferirse, aunque los límites de tamaño estén bien. Por defecto suele ser de 30 a 60 segundos. Síntoma: la subida arranca, la barra de progreso llega al 80% y luego falla con "Error HTTP".
• Límite de cuerpo de petición del servidor web. nginx tiene una directiva client_max_body_size (por defecto 1M, dolorosamente bajo para subir medios). Apache rara vez lo topa por defecto, pero los proxies inversos, balanceadores de carga y CDNs (Cloudflare en particular tiene un tope de 100M en planes gratuitos, 200M en Pro y 500M en Business) imponen sus propios techos. Síntoma: una página "413 Request Entity Too Large" que no se parece en nada a WordPress, porque WordPress nunca recibió la petición.

El tamaño máximo real de subida es el más bajo de los cuatro. WordPress muestra el límite efectivo en la propia página de subida: abre Medios, Añadir nuevo en el admin y busca la pequeña línea "Tamaño máximo de archivo de subida" debajo del área de subida.

¿Cuánto necesitas realmente?

Un modelo mental práctico:

• 32M. Suficiente para imágenes típicas, PDFs y archivos de audio pequeños. El valor por defecto en hosts compartidos conservadores.
• 64M. Cómodo para la mayoría de sitios editoriales. Aguanta ráfagas de fotos de una cámara moderna, PDFs grandes y clips de vídeo cortos.
• De 128M a 256M. El rango adecuado para sitios que suben con regularidad vídeo, archivos PSD grandes, assets de diseño o zips de temas y plugins en una instalación autogestionada.
• Por encima de 256M. Sobre todo relevante para sitios con mucho vídeo, feeds de podcast con archivos de audio grandes o plataformas de cursos con material de clase descargable. Vale la pena pensar si el archivo realmente tiene que vivir en el servidor de WordPress, o si un servicio como Vimeo, YouTube, Bunny Stream o un bucket S3 dedicado encaja mejor. WordPress no está optimizado para servir archivos multimedia grandes a escala.

Un detalle que la gente pasa por alto: WordPress también tiene su propio tope interno. Por defecto no impone un límite de tamaño más allá de lo que PHP permite, así que en la mayoría de hosts los ajustes de PHP son lo único en juego. El filtro upload_size_limit existe si quieres poner un tope específico de proyecto (útil en multisitio para dar a distintos roles distintos límites), pero solo puede bajar el límite efectivo, nunca subirlo más allá de PHP.

Opción 1: Subir los límites de PHP desde el panel de tu hoster

Casi siempre es el punto de partida correcto. La mayoría de hosts en 2026 exponen los ajustes relevantes en su panel y los cambios surten efecto en segundos.

cPanel (IONOS, Hostinger, muchos revendedores)

Ve a MultiPHP INI Editor, selecciona tu dominio y ajusta:

• upload_max_filesize al valor objetivo (p. ej. 128M)
• post_max_size al mismo valor o superior (p. ej. 128M)
• max_execution_time a al menos 300 segundos para archivos grandes
• max_input_time al mismo valor
• memory_limit a 256M o superior (las subidas se cargan brevemente en memoria durante el procesado)

Guarda. El cambio está activo de inmediato.

Plesk (All Inkl, DomainFactory, muchos hosts alemanes)

Abre el dominio en Plesk, haz clic en PHP Settings, baja hasta "Performance and security settings". Los campos son los mismos que en cPanel. Guarda y los valores se aplican en la siguiente petición.

Hosting WordPress gestionado (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Estos hosts casi siempre vienen con valores por defecto sensatos (típicamente entre 64M y 128M). Si el límite sigue siendo demasiado bajo para tu caso, el panel suele tener un control deslizante o un campo de entrada. Algunos hosts (WP Engine, Pressable) topan el máximo absoluto y exigen un ticket de soporte a partir de cierto tamaño, normalmente porque su pipeline de subida prevalida los archivos contra un CDN. Esos tickets se contestan en horas, no en días.

Opción 2: .user.ini en el raíz de WordPress

Si tu host ejecuta PHP vía FastCGI o PHP FPM (lo cual es básicamente cualquier host moderno) pero no expone un panel de ajustes, puedes dejar un archivo .user.ini directamente en el directorio raíz de WordPress:

upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

PHP recoge .user.ini automáticamente. La única peculiaridad es un tiempo de caché por defecto de cinco minutos (controlado por el ajuste user_ini.cache_ttl), así que los cambios no siempre se aplican en la siguiente petición.

Verifica con la página Salud del sitio de WordPress: Herramientas, Salud del sitio, Información, Servidor muestra el upload_max_filesize y post_max_size activos. Si los valores siguen coincidiendo con los antiguos por defecto tras diez minutos, el host o desactiva el soporte de .user.ini o ejecuta PHP en un modo que lo ignora. Continúa con la Opción 3.

Opción 3: php.ini en un servidor autogestionado

En un VPS o servidor dedicado en el que controlas PHP directamente, edita el php.ini activo. Encuéntralo con php --ini en la línea de comandos. La ruta varía según la distribución y la versión de PHP (típicamente /etc/php/8.2/fpm/php.ini en Debian o Ubuntu, /etc/php.ini en CentOS o RHEL).

Ajusta los mismos cinco valores que en la Opción 1, luego recarga PHP FPM:

sudo systemctl reload php8.2-fpm

(Ajusta el número de versión a tu instalación.) En Apache con mod_php, reinicia Apache en su lugar. El cambio se aplica de inmediato, sin más pasos.

Opción 4: nginx client_max_body_size

Esta es la trampa que pilla a mucha gente en nginx autogestionado. PHP puede estar configurado para aceptar subidas de 1GB, pero si nginx sigue topado a 1M (el valor por defecto), la subida nunca llega a PHP. El navegador muestra un genérico "413 Request Entity Too Large", a menudo sin ninguna pista de que nginx es el responsable.

Añade la directiva al bloque server de tu sitio, o globalmente en el bloque http de nginx.conf:

client_max_body_size 128M;

Recarga nginx con sudo nginx -t && sudo systemctl reload nginx. El valor debería igualar o superar tu post_max_size de PHP. No pasa nada por ponerlo un poco más alto; el límite real sigue siendo PHP.

Opción 5: Apache con .htaccess (legado)

En setups antiguos de Apache que ejecutan mod_php (raro en hosting moderno, común en servidores legados), puedes meter las directivas de PHP directamente en .htaccess en el raíz de WordPress:

php_value upload_max_filesize 128M
php_value post_max_size 128M
php_value max_execution_time 300
php_value max_input_time 300
php_value memory_limit 256M

Si tu host ejecuta PHP vía FastCGI o PHP FPM (que es básicamente cualquier host moderno), esta directiva tira un error 500 o se ignora en silencio. Usa .user.ini de la Opción 2 en su lugar.

Opción 6: Cuando el límite está en la capa de CDN o proxy

Si has configurado PHP y el servidor web para permitir subidas de 256M, pero la subida sigue fallando, digamos, en 100M, el cuello de botella está en algún punto delante del servidor de WordPress. Sospechosos habituales:

• Cloudflare topa el tamaño de cuerpo por plan: 100M en Free, 200M en Pro, 500M en Business, 500M en Enterprise (subible bajo petición). Para subidas más grandes, o subes de plan, o excluyes el admin de WordPress del proxy poniendo el registro DNS a "DNS only" para /wp-admin/ mediante una Page Rule, o usas un subdominio directo que esquive Cloudflare para las subidas.
• Cloudways tiene una capa varnish con un límite de cuerpo bajo por defecto. Su panel expone el ajuste en "Application Settings, Server Configurations".
• Proxies inversos delante de nginx (HAProxy, Traefik) tienen sus propios límites de cuerpo que hay que subir en sus respectivos archivos de configuración.
• Algunos cortafuegos y plugins de seguridad a nivel de WAF (Sucuri, Wordfence Premium con WAF en la nube) topan tamaños de subida por defecto. Su panel de ajustes tiene una opción separada para esto.

Truco diagnóstico: prueba la subida desde dentro del propio servidor usando curl con un archivo local. Si la subida funciona local pero falla a través de la URL pública, el límite está en una capa de proxy o CDN, no en PHP.

Cómo verificar que los nuevos límites están activos

1. Abre Herramientas, Salud del sitio, Información en el admin de WordPress.
2. Despliega la sección Servidor. Busca upload_max_filesize, post_max_size, max_execution_time y memory_limit. Todos deberían reflejar los nuevos valores.
3. Para una comprobación más rápida, abre Medios, Añadir nuevo. La línea "Tamaño máximo de archivo de subida" al pie del área de subida debería mostrar el nuevo límite efectivo.
4. Prueba la subida real que disparó el problema. Si sigue fallando, fíjate exactamente en qué mensaje de error sale; eso señala cuál de los cuatro límites sigue siendo demasiado bajo.

Qué hacer cuando el archivo es genuinamente demasiado grande para una subida HTTP

Por encima de 500M a 1GB, las subidas por navegador dejan de ser prácticas independientemente de los ajustes del servidor. La conexión TCP se vuelve inestable, los proxies intermedios agotan tiempo y un solo hipo de red implica empezar de cero. Dos alternativas más cuerdas:

• Subir vía SFTP e importar desde WordPress. Coloca el archivo directamente en wp-content/uploads/AÑO/MES/ vía SFTP, luego usa un plugin como Add From Server o Media Sync para registrarlo en la biblioteca de medios. WordPress genera los metadatos y miniaturas como si lo hubieras subido normal.
• Servicios de medios externos. Para vídeo en concreto, Vimeo, Bunny Stream, Cloudflare Stream y YouTube manejan el alojamiento y el streaming adaptativo mucho mejor que el core de WordPress. La mayoría de temas y maquetadores modernos los integran de forma nativa, incluyendo miniaturas autogeneradas. Misma lógica para audio (Soundcloud, Spotify for podcasters) y descargas de archivos grandes (S3 con CloudFront o Bunny CDN delante).

Alojar un vídeo en bruto de 5GB en hosting WordPress compartido y servirlo directamente es técnicamente posible pero rara vez es la decisión correcta. Los costes de ancho de banda, la falta de bitrate adaptativo y la carga sobre un único worker PHP por espectador simultáneo apuntan todos hacia el alojamiento dedicado de medios.

Errores comunes a evitar

• Subir upload_max_filesize sin subir post_max_size a la vez. La subida falla en silencio porque toda la petición POST supera el menor de los dos. Cámbialos siempre juntos.
• Poner valores absurdamente altos "por si acaso". Un límite de subida de 4G en un servidor con 4GB totales de RAM es un vector de denegación de servicio. PHP carga partes de la subida en memoria durante el procesado. Elige un valor que refleje lo que realmente subes, más algo de margen.
• Olvidar max_execution_time. Una subida de 500MB sobre una conexión de 10 Mbit/s tarda unos siete minutos. Si max_execution_time está en el valor por defecto de 30 segundos, la petición se mata a media subida sin importar los límites de tamaño.
• Editar el php.ini equivocado. Un error frecuente en sistemas con varias versiones de PHP instaladas (p. ej. 7.4 y 8.2 ambas presentes pero solo una activa). El comando php --ini en línea de comandos puede apuntar a un php.ini distinto del que PHP FPM usa para el servidor web. Salud del sitio es la fuente fiable.

Para la mayoría de los casos, dos minutos en el panel del hoster subiendo cinco valores a defaults razonables resuelven el problema permanentemente. Los mensajes de error en torno a los límites de subida están desafortunadamente redactados de forma que suenan a problemas técnicos oscuros, pero el arreglo real es mecánico y está bien documentado. Una vez los límites están dimensionados a tu carga real, este es uno de los temas de WordPress que no necesita volver a aparecer.