WordPress erreur 413 : corriger Request Entity Too Large

Vous tentez d’importer une image ou une vidéo dans la médiathèque WordPress, et votre navigateur répond avec un message d’erreur sans vous dire pourquoi. Parfois c’est un écran blanc, parfois un bloc JSON avec 413 Request Entity Too Large, parfois juste un chargement qui s’arrête. Dans les trois cas, la cause est identique : votre serveur refuse de traiter un fichier parce qu’il dépasse la limite d’upload configurée.

L’erreur 413 WordPress survient quand la taille du fichier envoyé dépasse la valeur upload_max_filesize ou post_max_size de PHP, ou la directive client_max_body_size de Nginx. La correction prend moins de cinq minutes et ne nécessite aucun plugin.

Comprendre l’erreur 413

Le code HTTP 413 signifie littéralement « l’entité de la requête est trop grande ». Votre navigateur a envoyé un fichier au serveur, mais le serveur a refusé de le lire entièrement parce qu’il dépasse une limite définie côté serveur ou côté PHP.

Sur un hébergement mutualisé comme o2switch, la limite par défaut est souvent fixée à 2 Mo pour PHP. C’est largement insuffisant pour des photos en haute résolution (5 à 15 Mo), des PDF, ou des fichiers audio. WordPress affiche parfois une version allégée de l’erreur dans l’interface d’import : « Le fichier dépasse la taille maximale autorisée ». Dans d’autres cas, c’est directement le serveur web qui répond 413 avant même que WordPress ne soit consulté.

Les trois limites à connaître

Trois valeurs indépendantes contrôlent la taille d’upload. Si l’une d’elles est trop basse, l’erreur 413 apparaît même si les deux autres sont correctement configurées.

• upload_max_filesize : taille maximale d’un seul fichier PHP. C’est la valeur la plus souvent en cause.
• post_max_size : taille totale de la requête POST (fichier + données du formulaire). Doit toujours être supérieure ou égale à upload_max_filesize.
• client_max_body_size : directive Nginx équivalente, définie côté serveur web. Sur Apache, c’est LimitRequestBody. Sur un mutualisé, vous n’avez généralement pas accès à ces valeurs, mais l’hébergeur les fixe à des niveaux suffisamment élevés.

Diagnostiquer la limite actuelle

Avant de corriger, identifiez quelle limite est active sur votre installation. La méthode la plus rapide est la page Médias de votre tableau de bord WordPress : allez dans Médias > Ajouter et regardez la mention « Taille de fichier maximale » indiquée sous la zone d’import.

Pour un diagnostic plus précis, créez un fichier info.php temporaire à la racine de votre site :

<?php phpinfo(); ?>

Ouvrez https://votresite.com/info.php dans votre navigateur, recherchez les lignes upload_max_filesize et post_max_size, puis supprimez immédiatement le fichier. Ne laissez jamais un phpinfo public en production.

Solution 1 : modifier php.ini ou .user.ini

C’est la méthode la plus propre et la plus durable. Sur la plupart des hébergements mutualisés (o2switch, OVH, Infomaniak), vous pouvez créer un fichier .user.ini à la racine de votre WordPress (même dossier que wp-config.php) :

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

Les valeurs recommandées sont 64 Mo pour les fichiers et 128 Mo pour la requête POST. Si votre hébergeur vous donne accès à un fichier php.ini global via cPanel, modifiez-le directement à la place du .user.ini. Les deux ont le même effet.

Après avoir créé ou modifié le fichier, attendez 5 minutes (PHP-FPM met à jour les paramètres en cache) puis vérifiez la page Médias.

Solution 2 : ajouter des directives dans .htaccess

Si votre hébergeur utilise Apache et que vous ne pouvez pas modifier php.ini, ajoutez ces lignes dans le fichier .htaccess à la racine de WordPress, avant le bloc WordPress existant :

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

Attention : cette méthode ne fonctionne que si votre hébergement utilise le mode mod_php. Sur PHP-FPM (mode FastCGI, de plus en plus courant), ces directives sont ignorées silencieusement. Si votre .htaccess ne produit aucun effet, utilisez le .user.ini à la place.

Solution 3 : via wp-config.php

WordPress expose un filtre upload_size_limit et une constante pour définir la taille maximale côté application. Ajoutez cette ligne dans wp-config.php, avant la ligne /* C'est tout */ :

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

Cette constante agit sur la limite mémoire de WordPress, pas directement sur upload_max_filesize. Elle est utile si vos importations échouent par manque de mémoire plutôt que par la taille du fichier. Pour la taille d’upload, préférez les méthodes 1 ou 2.

Solution 4 : via functions.php du thème

Vous pouvez forcer la limite côté WordPress (sans toucher à PHP) avec ce filtre dans le fichier functions.php de votre thème actif ou d’un plugin Must Use :

add_filter( 'upload_size_limit', function( $size ) {
    return 64 * 1024 * 1024; // 64 Mo
} );

Cette méthode modifie la valeur affichée dans l’interface WordPress et peut débloquer certains imports, mais elle ne dépasse jamais la limite définie par PHP. Si PHP bloque à 2 Mo, ce filtre ne permettra pas d’importer 64 Mo. Elle est donc complémentaire, pas autonome.

Solution 5 : cPanel (hébergement mutualisé)

Sur o2switch et les hébergements cPanel compatibles, un raccourci existe. Connectez-vous à votre espace cPanel, cherchez la section Logiciels puis Sélecteur de version PHP (ou MultiPHP INI Editor). Vous trouverez directement les champs upload_max_filesize et post_max_size sous forme de formulaire. Modifiez les valeurs, enregistrez. Le .user.ini est mis à jour automatiquement.

Solution 6 : Nginx (VPS ou serveur dédié)

Si votre site tourne derrière Nginx (VPS, serveur dédié, ou Nginx en reverse proxy devant Apache), c’est Nginx qui bloque la requête avant même que PHP ne soit consulté. Éditez votre fichier de configuration Nginx (bloc server ou location) :

client_max_body_size 64M;

Puis rechargez Nginx :

sudo nginx -t && sudo systemctl reload nginx

Sur un mutualisé, vous n’avez pas accès à la configuration Nginx. Si vous êtes sur un mutualisé et que les solutions PHP ne fonctionnent pas, contactez le support de votre hébergeur pour qu’il ajuste client_max_body_size.

Vérifier que la correction est active

Après toute modification, rechargez la page Médias > Ajouter dans votre tableau de bord. La mention de taille maximale doit refléter la nouvelle valeur. Si elle n’a pas changé :

• Attendez 5 minutes (cache PHP-FPM)
• Purgez le cache LiteSpeed ou votre plugin de cache
• Vérifiez qu’il n’existe pas un autre fichier .user.ini ou php.ini dans un sous-dossier qui écrase vos paramètres
• Contrôlez que votre hébergeur n’impose pas une limite maximale (certains hébergements plafonnent à 32 Mo)

Si l’erreur 413 persistait après augmentation de la limite PHP, l’origine est probablement Nginx ou un WAF (pare-feu applicatif) en amont. Sur un CDN comme Cloudflare, la limite de taille de corps des requêtes dépend de votre offre (Free : 100 Mo par défaut).

Erreurs fréquemment confondues avec le 413

Deux autres erreurs produisent un comportement similaire au 413 mais ont des causes distinctes :

• Erreur 504 : le serveur a bien reçu le fichier mais PHP a dépassé le délai d’exécution pendant le traitement (souvent lors de la génération de miniatures pour de très grandes images).
• Erreur 500 : le fichier est reçu, traité, mais un script PHP plante en cours de route. Cause fréquente : la limite mémoire est atteinte pendant la création des variantes d’image.
• Page blanche : variante silencieuse du 500, souvent liée au même problème de mémoire ou d’exécution.

Bonnes pratiques pour éviter le retour de l’erreur

Une fois la limite augmentée, adoptez quelques réflexes pour éviter de saturer les ressources du serveur :

• Optimisez les images avant de les importer (Squoosh, TinyPNG, ou un plugin comme Imagify). Une photo de 8 Mo peut descendre à 500 Ko sans perte visible.
• Pour les vidéos, hébergez-les sur YouTube ou Vimeo et intégrez-les dans WordPress plutôt que de les uploader directement.
• Si vous importez souvent des fichiers lourds, augmentez max_execution_time en même temps que upload_max_filesize : PHP peut avoir besoin de plus de temps pour traiter et redimensionner les images.
• Vérifiez régulièrement la taille du dossier wp-content/uploads/ : un serveur dont le disque est plein refuse également les importations.

Si le refus porte sur une demande mal formée, notre guide sur WordPress erreur 400 aide à distinguer cookies, URL, REST API et pare feu.

FAQ

Pourquoi WordPress affiche 2 Mo comme limite maximale ?

La valeur par défaut de upload_max_filesize dans PHP est souvent fixée à 2 Mo par les hébergeurs pour limiter la charge des serveurs mutualisés. Ce n’est pas une contrainte WordPress, c’est une configuration PHP ou serveur que vous pouvez modifier selon les méthodes décrites dans cet article.

La limite upload_max_filesize doit-elle être inférieure à post_max_size ?

Oui. La règle est : post_max_size doit être supérieure à upload_max_filesize. Si vous fixez upload_max_filesize = 64M et que post_max_size = 8M, WordPress bloquera les imports à 8 Mo, pas 64 Mo. Définissez toujours les deux ensemble.

Le .user.ini fonctionne-t-il sur tous les hébergements ?

Le fichier .user.ini fonctionne avec PHP-FPM, le mode d’exécution PHP le plus courant sur les hébergements mutualisés modernes (o2switch, OVH Performance, Infomaniak). Il ne fonctionne pas avec le mode CGI ou SuPHP. En cas de doute, vérifiez avec votre hébergeur ou testez directement.

L’erreur 413 peut-elle venir de Cloudflare ?

Oui, si votre site est derrière Cloudflare. Sur l’offre Free, la limite par défaut est de 100 Mo pour les requêtes HTTP. Cette limite est rarement en cause pour des imports WordPress standards, mais sur les offres Pro/Business vous pouvez la configurer. Si votre limite PHP est bien configurée et que l’erreur persiste, vérifiez les logs Cloudflare.

Comment vérifier que la nouvelle limite est bien prise en compte ?

La façon la plus simple est d’aller dans Médias > Ajouter de votre tableau de bord WordPress et de lire la mention de taille maximale. Pour une vérification technique, créez un fichier phpinfo.php temporaire à la racine, ouvrez-le dans votre navigateur et cherchez les lignes upload_max_filesize et post_max_size. Supprimez ce fichier immédiatement après.

Sources : Documentation PHP : upload_max_filesize | Documentation Nginx : client_max_body_size | WordPress Developer : wp_max_upload_size | HTTP 413 Reference | MDN : 413 Content Too Large | Documentation PHP : post_max_size