Contact
← Terug naar kennisbank HOSTING

413 Payload Too Large — uitgelegd en opgelost

De HTTP-status die zegt: "jouw upload is groter dan ik wil verwerken". Komt vooral voor bij het uploaden van foto's, video's en PDF's via de WordPress media-bibliotheek of een form. De frustrerende kant: er zijn vier plekken in de stack waar een limiet kan zitten (PHP, Apache, Nginx, Cloudflare), en één te lage waarde geeft 413, ongeacht wat de andere drie staan. Deze gids legt uit waar elke limiet zit, hoe je 'm verhoogt, en hoe je achter de daadwerkelijk geldende waarden komt.

9 min lezen · Laatst gecheckt:

Waarom je 413 krijgt

Bij elke upload reist je bestand door een keten van software, en elk onderdeel heeft z'n eigen plafond. De zwakste schakel bepaalt de werkelijke limiet:

  1. Cloudflare / CDN — Free-plan: 100MB hard, Pro: 200MB, Business: 500MB
  2. Nginx (web-server of reverse-proxy) — client_max_body_size, default 1MB
  3. Apache — LimitRequestBody, default unlimited (maar Plesk/cPanel kunnen 'm forceren)
  4. PHP — upload_max_filesize en post_max_size, default 2MB op veel hosters

Krijg je 413 op een 50MB-bestand met PHP-limit op 64M? Dan zit 't waarschijnlijk niet bij PHP, maar één laag erboven. Eerste stap: vinden welke laag de boosdoener is.

Stap 1: ontdek de daadwerkelijk geldende limiet

Maak een tijdelijk PHP-bestand info.php in je webroot:

<?php phpinfo(); ?>

Bezoek https://jouwdomein.nl/info.php, zoek met Ctrl+F naar:

  • upload_max_filesize — per-bestand limiet
  • post_max_size — totale request-body limiet
  • memory_limit — PHP-geheugen per request
  • max_input_time — hoelang PHP mag spenderen aan request-parsing

Verwijder info.php direct na controle — het lekt server-info die je niet publiek wil hebben.

Of via WordPress: Tools > Site Health > Info > Server. Of bij Media > Add new: WordPress toont "Maximaal uploadbaar bestand: 8MB".

Stap 2: verhoog de PHP-limieten

PHP is meestal de eerste verdachte. Drie plekken om aan te passen:

php.ini (vol toegang nodig)

upload_max_filesize = 64M
post_max_size = 80M
memory_limit = 128M
max_input_time = 300
max_execution_time = 300

Vuistregel: post_max_size > upload_max_filesize (post bevat ook form-data), memory_limit > post_max_size.

.user.ini (shared hosting, geen php.ini-toegang)

Plaats een .user.ini-bestand in je WordPress-webroot:

upload_max_filesize = 64M
post_max_size = 80M
memory_limit = 128M

Werkt op de meeste shared hosters met PHP-FPM. Cache-vertraging: kan tot 5 minuten duren voor de waardes actief zijn (user_ini.cache_ttl default 300).

.htaccess (alleen mod_php)

php_value upload_max_filesize 64M
php_value post_max_size 80M
php_value memory_limit 128M

Werkt alleen als je hoster mod_php gebruikt — bij PHP-FPM (modern, default op Plesk/DirectAdmin/cPanel) negeert Apache deze regels en geeft 500-error. Test: zet php_value en herlaad — 500-error = PHP-FPM, geen 500 = mod_php.

WordPress wp-config.php

// Verhoog memory voor uploads + media-processing
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Dit raakt PHP-limieten niet, maar voorkomt dat WordPress zelf out-of-memory gaat tijdens image-processing na de upload (resizing genereert thumbnails — dat vreet RAM).

Stap 3: check Apache LimitRequestBody

Apache heeft default geen limiet, maar Plesk en sommige cPanel-instellingen forceren wel een. Plesk default is 128MB op nieuwe sites.

In Plesk: "Apache & nginx Settings" → "Maximum size of uploaded files". cPanel: MultiPHP INI Editor.

Of in .htaccess:

LimitRequestBody 80000000  # in bytes (~76MB)

Werkt op Apache zonder extra modules.

Stap 4: check Nginx client_max_body_size

Als je Nginx als reverse-proxy vóór Apache draait (Plesk default), of pure Nginx hebt, is client_max_body_size de boosdoener. Default: 1MB — krijgt iedereen die 'n grotere upload doet meteen 413.

In Plesk: "Apache & nginx Settings" → "Additional nginx directives":

client_max_body_size 80M;
client_body_timeout 300s;

In een eigen Nginx-config (/etc/nginx/sites-available/jouwsite):

server {
    listen 443 ssl;
    server_name jouwdomein.nl;

    client_max_body_size 80M;
    client_body_timeout 300s;

    # rest van je config
}

Daarna nginx -t om de config te checken, dan systemctl reload nginx (of "Apply" in Plesk).

Stap 5: Cloudflare en CDN's

Cloudflare heeft per plan een hard upload-plafond. Je kunt deze niet verhogen via een config-knop — het is een infrastructuur-limiet:

  • Free: 100MB
  • Pro: 200MB
  • Business: 500MB
  • Enterprise: 5GB

Workarounds voor grote uploads:

  • Subdomein bypass: maak upload.jouwdomein.nl en zet de DNS-proxy in Cloudflare uit (grijze wolk). Verkeer gaat dan rechtstreeks naar je origin, geen Cloudflare-limit.
  • Chunked upload: plugin als Big File Uploads (Tuxedo) splitst grote bestanden in chunks van 5MB en herzet ze server-side. Werkt voor video-uploads.
  • Direct-to-S3: upload-plugins die rechtstreeks naar S3 of R2 uploaden, browser-naar-storage zonder via je server.

Specifieke WordPress-scenario's

Media-bibliotheek uploadt geen video

Video van 200MB en je krijgt "is groter dan de maximum upload-grootte voor deze site"? Geen 413 maar een vriendelijkere variant van dezelfde fout — WordPress heeft de upload tegengehouden vóórdat de server 'm zag.

Fix: pas alle vier de lagen aan, en in WordPress zelf is geen extra config nodig — WordPress neemt de PHP-waarde over.

Plugin-installatie via dashboard

Plugin-zip van 30MB uploaden via Plugins > New > Upload Plugin en je krijgt 413? Zelfde verhaal — check je vier limieten. Workaround: upload via FTP/SFTP naar /wp-content/plugins/.

Klant kan een formulier-bijlage niet versturen

Contact Form 7 / Gravity Forms / WPForms met file-attachment-veld. Klant probeert PDF van 15MB te versturen, krijgt 413. Forms vertrouwen op de standaard PHP-upload-instellingen, dus zelfde fix: PHP + Apache + Nginx + (eventueel) Cloudflare verhogen.

Veelgestelde vragen

Wat veroorzaakt een 413-fout in WordPress?

Een limiet ergens in de stack: PHP (upload_max_filesize, post_max_size), Apache (LimitRequestBody), Nginx (client_max_body_size), of Cloudflare/CDN. Één te lage waarde en je krijgt 413, ongeacht de andere drie.

Hoe verhoog ik de upload-limiet in WordPress?

Eerst check de huidige limiet via Site Health of phpinfo(). Verhoog vervolgens in php.ini / .user.ini / .htaccess: upload_max_filesize en post_max_size beide naar bv. 64M. Op shared hosting waar je niet bij php.ini kunt, gebruik .user.ini.

Welke twee waardes moet je samen verhogen?

upload_max_filesize én post_max_size. post_max_size moet groter zijn (bevat ook andere form-data). En je memory_limit moet groter dan post_max_size zijn, anders kan PHP de request niet eens parsen.

Krijg ik 413 ondanks dat php.ini hoog staat?

Twee oorzaken: (1) Nginx als reverse-proxy heeft z'n eigen client_max_body_size die boven PHP-FPM zit, (2) Cloudflare/CDN-plafond. Op Cloudflare Free is dat 100MB hard.

Geeft 413 ook op kleine uploads — wat is er aan de hand?

Mogelijk staat post_max_size lager dan upload_max_filesize, of je server forceert een hard plafond. Check daadwerkelijke waardes via phpinfo().