De maximale uploadgrootte voor bestanden in WordPress verhogen

U sleept een video van 60MB in de WordPress-mediabibliotheek, wacht een paar seconden en krijgt een van drie foutmeldingen terug: "The uploaded file exceeds the upload_max_filesize directive in php.ini", "413 Request Entity Too Large", of simpelweg "HTTP-fout" zonder verdere uitleg. De oplossing is bijna altijd het verhogen van de maximale uploadgrootte, maar zoals bij de meeste WordPress-limietonderwerpen is er niet maar één limiet. Er zijn er vier, ze leven op verschillende plaatsen en de laagste wint. Deze gids legt uit welke limiet welke foutmelding veroorzaakt en hoe u elk daarvan verhoogt op de verschillende hostingsetups.

Welke limiet is verantwoordelijk voor welke fout?

Vier afzonderlijke instellingen kunnen een upload blokkeren. Weten welke u getroffen heeft, bespaart veel trial-and-error.

PHP upload_max_filesize. Het harde plafond op de grootte van een enkel geüpload bestand. Standaard op de meeste hosts is 2M tot 64M. Als uw bestand dit overschrijdt, toont WordPress de expliciete melding "uploaded file exceeds the upload_max_filesize directive".
PHP post_max_size. De maximale grootte van het hele POST-verzoek, inclusief het bestand plus alle andere formuliervelden. Moet minstens zo groot zijn als upload_max_filesize; anders mislukt de upload stilletjes voordat WordPress het zelfs ziet. Standaard is meestal 8M tot 64M.
PHP max_execution_time en max_input_time. Tijdslimieten in seconden. Een grote upload over een trage verbinding kan de tijdslimiet bereiken voordat het bestand klaar is met overdragen, zelfs als de groottelimieten in orde zijn. Standaard is meestal 30 tot 60 seconden. Symptoom: upload start, voortgangsbalk komt tot 80%, mislukt dan met "HTTP-fout".
Webserver-verzoeklichaamlimiet. nginx heeft een client_max_body_size-richtlijn (standaard 1M, pijnlijk laag voor media-uploads). Apache plafoneert dit zelden standaard, maar reverse proxies, load balancers en CDN's (vooral Cloudflare heeft een 100M-cap op gratis abonnementen, 200M op Pro, 500M op Business) hanteren allemaal hun eigen plafonds. Symptoom: een "413 Request Entity Too Large"-pagina die er helemaal niet uitziet als WordPress, omdat WordPress het verzoek nooit heeft ontvangen.

De werkelijke maximale uploadgrootte is de laagste van de vier. WordPress toont de effectieve limiet op de uploadpagina zelf: open Media, Nieuwe toevoegen in de admin en kijk naar de kleine regel "Maximale uploadbestandsgrootte" onder het uploadgebied.

Hoeveel hebt u eigenlijk nodig?

Een praktisch mentaal model:

32M. Voldoende voor typische afbeeldingen, PDF's en kleine audiobestanden. De standaard op conservatieve gedeelde hosts.
64M. Comfortabel voor de meeste redactionele sites. Verwerkt fotobursts van een moderne camera, grotere PDF's en korte videoclips.
128M tot 256M. Het juiste bereik voor sites die regelmatig video, grote PSD-bestanden, ontwerpactiva of thema- en plug-in-zip-bestanden voor een zelfbeheerde installatie uploaden.
Boven 256M. Vooral relevant voor video-zware sites, podcastfeeds met grote audiobestanden of cursusplatforms met downloadbaar lesmateriaal. Het is de moeite waard om na te denken of het bestand werkelijk op de WordPress-server moet staan, of dat een service zoals Vimeo, YouTube, Bunny Stream of een speciale S3-bucket beter past. WordPress is niet geoptimaliseerd voor het op grote schaal serveren van grote mediabestanden.

Eén detail dat mensen missen: WordPress heeft ook zijn eigen interne plafond. Standaard legt het geen groottelimiet op buiten wat PHP toestaat, dus op de meeste hosts zijn de PHP-instellingen het enige dat in het spel is. Het filter upload_size_limit bestaat als u een projectspecifiek plafond wilt instellen (handig in multisite om verschillende rollen verschillende limieten te geven), maar het kan de effectieve limiet alleen verlagen, nooit boven PHP verhogen.

Optie 1: PHP-limieten verhogen via het paneel van uw hoster

Bijna altijd het juiste startpunt. De meeste hosts in 2026 bieden de relevante instellingen in hun dashboard, en wijzigingen worden binnen seconden actief.

cPanel (IONOS, Hostinger, veel resellers)

Ga naar MultiPHP INI Editor, selecteer uw domein en pas aan:

upload_max_filesize naar uw doelwaarde (bijv. 128M)
post_max_size naar dezelfde of hogere (bijv. 128M)
max_execution_time naar minstens 300 seconden voor grote bestanden
max_input_time naar dezelfde waarde
memory_limit naar 256M of hoger (uploads worden tijdens verwerking kort in het geheugen geladen)

Sla op. De wijziging is direct actief.

Plesk (All Inkl, DomainFactory, veel Duitse hosts)

Open het domein in Plesk, klik op PHP-instellingen, scroll naar "Prestaties en beveiligingsinstellingen". De velden zijn dezelfde als voor cPanel. Sla op en de waarden gelden bij het volgende verzoek.

Beheerde WordPress-hosting (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Deze hosts leveren bijna altijd al verstandige standaardwaarden (meestal 64M tot 128M). Als de limiet nog te laag is voor uw gebruikssituatie, heeft het dashboard meestal een schuifregelaar of invoerveld. Een paar hosts (WP Engine, Pressable) plafonneren het absolute maximum en vereisen een supportticket boven een bepaalde grootte, meestal omdat hun uploadpijplijn bestanden vooraf valideert tegen een CDN. Die tickets worden binnen uren beantwoord, niet dagen.

Optie 2: .user.ini in de WordPress-root

Als uw host PHP draait via FastCGI of PHP FPM (wat in wezen elke moderne host is), maar geen instellingenpaneel biedt, kunt u een .user.ini-bestand rechtstreeks in de WordPress-rootmap plaatsen:

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

PHP pikt .user.ini automatisch op. De enige eigenaardigheid is een standaard cachetijd van vijf minuten (geregeld door de instelling user_ini.cache_ttl), dus wijzigingen worden niet altijd bij het allereerstvolgende verzoek actief.

Verifieer met de WordPress Site Health-pagina: Hulpmiddelen, Site Health, Info, Server toont de actieve upload_max_filesize en post_max_size. Als de waarden na tien minuten nog steeds overeenkomen met de oude standaardwaarden, schakelt de host ofwel .user.ini-ondersteuning uit ofwel draait PHP in een modus die het negeert. Ga verder met Optie 3.

Optie 3: php.ini op een zelfbeheerde server

Op een VPS of dedicated server waar u PHP rechtstreeks beheert, bewerk de actieve php.ini. Vind hem met php --ini op de commandoregel. Het pad varieert per distributie en PHP-versie (meestal /etc/php/8.2/fpm/php.ini op Debian of Ubuntu, /etc/php.ini op CentOS of RHEL).

Pas dezelfde vijf waarden aan als in Optie 1, herlaad dan PHP FPM:

sudo systemctl reload php8.2-fpm

(Pas het versienummer aan op uw installatie.) Op Apache met mod_php herstart in plaats daarvan Apache. De wijziging is onmiddellijk actief, geen verdere actie nodig.

Optie 4: nginx client_max_body_size

Dit is degene die veel mensen op zelfbeheerde nginx betrapt. PHP kan worden geconfigureerd om uploads van 1GB te accepteren, maar als nginx nog steeds is geplafonneerd op 1M (de standaard), bereikt de upload PHP nooit. De browser toont een generieke "413 Request Entity Too Large"-fout, vaak zonder enige aanwijzing dat nginx verantwoordelijk is.

Voeg de richtlijn toe aan het server-blok van uw site, of globaal in het http-blok van nginx.conf:

client_max_body_size 128M;

Herlaad nginx met sudo nginx -t && sudo systemctl reload nginx. De waarde moet overeenkomen met of hoger zijn dan uw PHP post_max_size. Er is geen kwaad in het iets hoger instellen; de werkelijke limiet is nog steeds PHP.

Optie 5: Apache met .htaccess (verouderd)

Op oudere Apache-setups die mod_php draaien (zeldzaam op moderne hosting, gebruikelijk op verouderde servers), kunt u de PHP-richtlijnen direct in .htaccess in de WordPress-root plaatsen:

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

Als uw host PHP draait via FastCGI of PHP FPM (wat in wezen elke moderne host is), gooit deze richtlijn een 500-fout of wordt deze stilletjes genegeerd. Gebruik in plaats daarvan .user.ini uit Optie 2.

Optie 6: Wanneer de limiet bij de CDN- of proxylaag ligt

Als u PHP en de webserver hebt geconfigureerd om uploads van 256M toe te staan, maar de upload nog steeds mislukt bij bijvoorbeeld 100M, ligt het knelpunt ergens voor de WordPress-server. Veelvoorkomende boosdoeners:

Cloudflare plafonneert lichaamsgrootte per abonnement: 100M op Free, 200M op Pro, 500M op Business, 500M op Enterprise (op verzoek verhoogd). Voor grotere uploads upgrade het abonnement, sluit de WordPress-admin uit van de proxy door de DNS-record op "DNS only" te zetten voor /wp-admin/ via een Page Rule, of gebruik een direct subdomein dat Cloudflare omzeilt voor uploads.
Cloudways heeft een varnish-laag die standaard een lage lichaamsgroottelimiet heeft. Hun dashboard bevat de instelling onder "Application Settings, Server Configurations".
Reverse proxies opgesteld voor nginx (HAProxy, Traefik) hebben allemaal hun eigen lichaamsgroottelimieten die in hun respectieve configuratiebestanden moeten worden verhoogd.
Sommige firewalls en beveiligingsplug-ins op WAF-niveau (Sucuri, Wordfence Premium met cloud WAF) plafonneren standaard uploadgroottes. Hun instellingenpaneel heeft een aparte optie hiervoor.

De diagnostische truc: probeer de upload van binnen de server zelf met curl en een lokaal bestand. Als de upload lokaal werkt maar via de openbare URL mislukt, ligt de limiet bij een proxy- of CDN-laag, niet in PHP.

Hoe verifieert u dat de nieuwe limieten actief zijn

Open Hulpmiddelen, Site Health, Info in de WordPress-admin.
Vouw de sectie Server uit. Zoek upload_max_filesize, post_max_size, max_execution_time en memory_limit. Ze zouden alle de nieuwe waarden moeten weerspiegelen.
Voor een snellere controle, open Media, Nieuwe toevoegen. De regel "Maximale uploadbestandsgrootte" onderaan het uploadgebied zou de nieuwe effectieve limiet moeten tonen.
Probeer de werkelijke upload die het probleem veroorzaakte. Als deze nog steeds mislukt, noteer dan precies welke foutmelding u krijgt; dat wijst naar welke van de vier limieten nog te laag is.

Wat te doen wanneer het bestand werkelijk te groot is voor een HTTP-upload

Boven 500M tot 1GB stoppen browseruploads praktisch te zijn ongeacht serverinstellingen. De TCP-verbinding wordt onstabiel, tussenliggende proxies time-out, en een enkele netwerkstoring betekent opnieuw beginnen. Twee verstandigere alternatieven:

Upload via SFTP en importeer via WordPress. Plaats het bestand rechtstreeks in wp-content/uploads/JAAR/MAAND/ via SFTP, gebruik dan een plug-in zoals Add From Server of Media Sync om het in de mediabibliotheek te registreren. WordPress genereert de metadata en miniaturen alsof u normaal had geüpload.
Externe mediadiensten. Specifiek voor video verzorgen Vimeo, Bunny Stream, Cloudflare Stream en YouTube hosting en adaptive streaming veel beter dan WordPress core. De meeste moderne thema's en page builders sluiten deze native in, inclusief automatisch gegenereerde miniaturen. Dezelfde logica voor audio (Soundcloud, Spotify for podcasters) en grote bestandsdownloads (S3 met een CloudFront of Bunny CDN ervoor).

Een ruwe video van 5GB hosten op gedeelde WordPress-hosting en deze rechtstreeks serveren is technisch mogelijk maar zelden de juiste keuze. De bandbreedtekosten, het ontbreken van adaptieve bitrate en de belasting op één PHP-worker per gelijktijdige kijker wijzen allemaal richting toegewijde mediahosting.

Veelgemaakte fouten om te vermijden

upload_max_filesize verhogen zonder post_max_size ernaast te verhogen. De upload mislukt stilletjes omdat het hele POST-verzoek de lagere van de twee overschrijdt. Wijzig ze altijd samen.
Absurd hoge waarden "voor de zekerheid" instellen. Een upload-limiet van 4G op een server met in totaal 4GB RAM is een denial-of-service-vector. PHP laadt delen van de upload tijdens verwerking in het geheugen. Kies een waarde die weerspiegelt wat u daadwerkelijk uploadt, plus speelruimte.
max_execution_time vergeten. Een upload van 500MB op een verbinding van 10 Mbit/s duurt ongeveer zeven minuten. Als max_execution_time de standaard 30 seconden is, wordt het verzoek halverwege de upload afgebroken ongeacht groottelimieten.
De verkeerde php.ini bewerken. Een veelgemaakte fout op systemen met meerdere PHP-versies geïnstalleerd (bijv. zowel 7.4 als 8.2 aanwezig, maar slechts één actief). Het commando php --ini op de commandoregel wijst mogelijk naar een andere php.ini dan degene die PHP FPM gebruikt voor de webserver. Site Health is de gezaghebbende bron.

Voor de meeste gevallen lossen twee minuten in het hosterpaneel met het verhogen van vijf waarden naar verstandige standaardwaarden het probleem permanent op. De foutmeldingen rond uploadgroottelimieten zijn helaas zo geformuleerd dat ze als obscure technische problemen klinken, maar de werkelijke oplossing is mechanisch en goed gedocumenteerd. Eenmaal de limieten zijn afgestemd op uw werkelijke werklast, is dit een van de WordPress-onderwerpen die niet meer hoeft op te komen.