Informática y Software Práctico

XAMPP configurar php.ini límites: sube upload_max_filesize ya

Post actualizado el día octubre 29, 2026 by DeiviSanzPlay

Si has intentado importar una base de datos grande o subir un tema pesado en WordPress sobre un servidor local y te topas con un error de tamaño máximo, el problema casi siempre está en los límites de PHP. Aprender XAMPP configurar php.ini límites es la vía más directa para resolver ese muro, y no requiere reinstalar nada: solo tocar el archivo correcto y reiniciar Apache.

El fallo típico aparece cuando phpMyAdmin rechaza un .sql de más de 2 MB o cuando un plugin devuelve «The uploaded file exceeds the upload_max_filesize directive». Ahí no hay magia: PHP está aplicando los valores por defecto que trae XAMPP, pensados para un entorno de pruebas conservador.

Qué archivo editar y por qué el php.ini equivocado no funciona

Antes de cambiar nada, conviene saber qué php.ini está leyendo Apache. XAMPP incluye varias copias: una en C:xamppphpphp.ini y otras dentro de carpetas como phpMyAdmin o apachebin. Si editas la equivocada, los valores no se aplican y seguirás viendo el mismo error, algo que descoloca bastante la primera vez.

La forma fiable de comprobarlo es abrir http://localhost/dashboard/phpinfo.php y buscar la línea «Loaded Configuration File». Esa ruta es la única que debes tocar. En instalaciones de XAMPP en Linux o macOS la ruta cambia (/opt/lampp/etc/php.ini), pero el principio es idéntico.

Los cuatro parámetros que de verdad importan

Dentro del archivo, busca estas directivas y ajústalas. No hace falta tocar todo el php.ini; con estas cuatro cubres la mayoría de escenarios:

  • upload_max_filesize: tamaño máximo por archivo subido. Si importas un .sql de 50 MB, súbelo a 64M o más.
  • post_max_size: debe ser mayor que upload_max_filesize, porque agrupa todos los datos del formulario. Un valor de 128M funciona bien cuando el anterior es 64M.
  • memory_limit: PHP necesita RAM para procesar la importación. 256M es un punto de partida razonable; 512M si trabajas con bases grandes.
  • max_execution_time: en segundos. Un script pesado puede tardar más de los 30 que trae por defecto. Subirlo a 300 evita cortes a mitad de proceso.

Un detalle que se pasa por alto: max_input_time también influye en la subida de archivos grandes. Si subes 64 MB por una conexión lenta, PHP puede abortar aunque el resto de límites estén holgados.

Un caso real con WordPress en local

En un entorno típico de desarrollo con WordPress sobre XAMPP, importar una copia de seguridad de un sitio mediano suele fallar en phpMyAdmin. Lo que funciona en la práctica: subir upload_max_filesize a 128M, post_max_size a 128M, memory_limit a 512M y max_execution_time a 600. Después, reiniciar Apache desde el panel de control de XAMPP (Stop y Start, no solo Restart, para asegurar que relee el archivo).

Si tras reiniciar phpMyAdmin sigue mostrando el mismo límite en su mensaje, revisa que no exista una copia de php.ini en xampp/phpMyAdmin con valores propios: phpMyAdmin puede tener su configuración de importación en config.inc.php mediante $cfg[‘UploadDir’] o $cfg[‘ExecTimeLimit’].

Cuándo esto no resuelve el problema

Subir los límites no sirve si el cuello de botella está en Apache o en el propio MySQL. Los timeouts de Apache (TimeOut en httpd.conf) y el max_allowed_packet de MySQL pueden bloquear la importación aunque PHP esté configurado con holgura. También hay un techo práctico: subir memory_limit a 2G en un equipo con 4 GB de RAM no acelera nada, solo arriesga que el sistema empiece a usar swap y todo se ralentice.

Otro límite que no se controla desde php.ini es el tamaño máximo de subida del navegador o del proxy local, poco frecuente en localhost pero relevante si expones XAMPP en red.

Comprobación después del cambio

Vuelve a phpinfo y verifica que «upload_max_filesize», «post_max_size» y «memory_limit» muestran los valores nuevos. Si no coinciden, el archivo editado no era el correcto o Apache no se reinició de verdad. La documentación oficial de PHP describe cada directiva y sus valores permitidos; la de Apache cubre los timeouts del servidor. Ninguna sustituye la comprobación en tu propio entorno, porque los valores razonables dependen del hardware y del tipo de proyecto.

Como referencia práctica, no prometo que estos ajustes sirvan para todos los casos: un proyecto con archivos de vídeo de varios GB requerirá otra estrategia (subida por fragmentos o FTP), no inflar php.ini. Los límites de PHP son un parche útil, no una solución universal.


Sobre el autor: DeiviSanzPlay — Soy David Sanz, Editor y Responsable de Contenidos. Mi trabajo consiste en revisar, corregir y mejorar los contenidos de este blog para que la información sea clara, útil y esté bien estructurada. Trabajo con diferentes temáticas y verticales, por lo que una parte importante de mi día a día es analizar cada contenido, cuidar la redacción y asegurar que el lector encuentre información de calidad. Me gusta prestar atención a los detalles. Desde una corrección de estilo hasta la organización de un artículo, todo cuenta cuando se trata de crear contenidos que realmente aporten valor y sean fáciles de entender. En este blog encontrarás artículos sobre diferentes temas y sectores. Mi responsabilidad es cuidar y supervisar cada contenido para que mantenga unos estándares de calidad y ofrezca una buena experiencia a quien nos visita. Porque para mí, un buen contenido no consiste únicamente en escribir. También hay que revisar, contrastar, ordenar y pensar en la persona que está al otro lado de la pantalla.

Perfiles verificables: Sitio web

Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.