413 Request Entity Too Large — sådan uploader du alligevel filen

Kort svar: 413 Request Entity Too Large betyder, at forespørgslen – typisk en filupload – er større, end et lag foran WordPress vil tage imod. Grænsen kan sidde i webserveren (nginx, Apache, LiteSpeed), i en firewall eller proxy som Cloudflare, og bagefter i PHP. Find først ud af, hvilket lag der svarer 413, og hæv så grænsen dér – eller gør filen mindre. At ændre noget i WordPress alene løser det aldrig.

Fagligt gennemgået: 2. oktober 2026

Fejlen dukker typisk op, når du uploader et stort billede, en video, en PDF, en plugin-zip eller en importfil. WordPress når slet ikke at se filen: forespørgslen bliver afvist, før PHP starter, og derfor kan WordPress heller ikke vise en pæn fejlbesked.

Den gode nyhed er, at 413 er en af de mest forudsigelige fejl, der findes. Det er en størrelsesgrænse, ikke en defekt. Alt under grænsen går igennem, alt over bliver afvist – og opgaven er at finde den grænse, der er lavest.

Før du ændrer noget: Notér den nuværende værdi, før du retter en grænse, så du kan sætte den tilbage. Hæv ikke grænserne til flere gigabyte “for en sikkerheds skyld” – store upload-grænser gør det lettere at overbelaste serveren, og en upload, der tager 20 minutter, kan stadig fejle på timeout. Ret helst ét lag ad gangen, og test efter hver ændring.

Hvor kommer 413 fra?

En upload passerer flere lag, før den lander i mediebiblioteket. Hvert lag har sin egen grænse, og det laveste lag bestemmer. Kun nogle af lagene svarer med netop statuskoden 413:

Lag	Indstilling	Typisk standard	Hvad du ser ved overskridelse
Cloudflare eller anden proxy	Grænse for request body pr. plan	Cloudflare: 100 MB på Free og Pro, 200 MB på Business	413 fra proxyen, før serveren ser noget
nginx	client_max_body_size	1 MB, hvis ingen har ændret den	413-side med “nginx” i bunden
Apache	LimitRequestBody	1 GB i nyere Apache 2.4-versioner	413 fra Apache
LiteSpeed	Max Request Body Size (serverindstilling)	Sat af udbyderen	413 fra LiteSpeed
Firewall/WAF (fx ModSecurity)	Grænse for request body	Sat af udbyderen	413 eller 403, afhængigt af regel
PHP	post_max_size og upload_max_filesize	8 MB og 2 MB i en standard php.ini	Ingen 413 – WordPress melder, at filen er for stor, eller uploaden fejler uden forklaring

Det sidste punkt er vigtigt. Når PHP-grænsen er for lav, får du ikke en 413, men en besked som “Filen overskrider upload_max_filesize” eller en generel HTTP-fejl ved upload. Ser du præcis 413, er det et lag før PHP, der siger nej.

1. Bekræft at det er 413 – og hvem der svarer

Åbn udviklerværktøjerne i browseren (F12), vælg fanen Netværk, og gentag uploaden. Klik på den røde forespørgsel, og kig på to ting:

• Statuskoden. Står der 413, er det en størrelsesgrænse. Står der 403, 500 eller 504, er det en anden fejl – se de relevante guides nederst.
• Svar-headeren server. cloudflare betyder, at proxyen afviste. nginx, Apache eller LiteSpeed peger på webserveren.

Har du adgang til en terminal, kan du teste grænsen uden WordPress. Lav en testfil af en kendt størrelse, og send den til sitet:

dd if=/dev/zero of=test-20m.bin bs=1M count=20
curl -s -o /dev/null -w "%{http_code}\n" -F "[email protected]" https://dinside.dk/

Svarer serveren 413, er grænsen under 20 MB et sted foran PHP. Svarer den noget andet (fx 200 eller 405), tog webserveren imod forespørgslen, og problemet ligger længere inde. Gentag med 5, 50 og 100 MB for at indkredse grænsen. Slet testfilen bagefter.

2. Find den grænse, WordPress kender

Gå til Værktøjer → Webstedets helbred → Info → Medieafvikling. Under “Maksimal størrelse for filoverførsel” står den laveste af de to PHP-værdier. Samme tal står under Medier → Tilføj ny.

Bemærk, at WordPress kun kender PHP-grænserne. Det tal siger intet om nginx, Apache, LiteSpeed eller Cloudflare. Står der 128 MB i Webstedets helbred, og du alligevel får 413 ved 30 MB, er det netop et af de andre lag.

Med WP-CLI kan du se det samme:

wp eval 'echo size_format( wp_max_upload_size() ) . PHP_EOL;'
wp eval 'echo ini_get("upload_max_filesize") . " / " . ini_get("post_max_size") . PHP_EOL;'

Brug ikke php -i direkte i terminalen som facit. PHP på kommandolinjen bruger ofte en anden konfiguration end den PHP, der kører websitet.

3. Hæv PHP-grænserne det rigtige sted

PHP giver ikke 413, men når du har løst webserverens grænse, rammer du PHP-grænsen som det næste. Ret derfor begge i samme omgang. To regler gælder:

• post_max_size skal være større end upload_max_filesize, fordi hele forespørgslen (fil plus formularfelter) skal kunne være der.
• memory_limit og max_execution_time skal kunne bære det, WordPress gør bagefter – fx at lave miniaturer af et stort billede.

Via kontrolpanelet

Har dit kontrolpanel en side med PHP-indstillinger, så brug den. Værdierne gælder for hele sitet, de overlever opdateringer, og de er til at finde igen. Typiske værdier til en side med billeder og PDF’er:

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

Via .user.ini, hvis du kun har filadgang

Kører PHP som PHP-FPM eller LiteSpeed LSAPI, kan du lægge en .user.ini i sitets rodmappe (samme mappe som wp-config.php):

upload_max_filesize = 64M
post_max_size = 128M

PHP læser filen med en forsinkelse – som standard op til fem minutter (user_ini.cache_ttl). Vent, og tjek så Webstedets helbred igen, før du konkluderer, at det ikke virkede. På servere, hvor PHP kører som Apache-modul, bruges i stedet php_value-linjer i .htaccess; på andre servere giver de linjer en 500-fejl, så fjern dem igen, hvis det sker.

Hvad du ikke skal gøre

Sæt ikke værdierne i wp-config.php eller i temaets functions.php med ini_set(). upload_max_filesize og post_max_size kan ikke ændres, mens scriptet kører – på det tidspunkt er forespørgslen allerede modtaget eller afvist. Filtret upload_size_limit i WordPress kan kun sænke grænsen, ikke hæve den over PHP’s.

4. Hæv webserverens grænse

Det er her, selve 413-fejlen sidder i de fleste tilfælde. Hvordan du ændrer den, afhænger af webserveren – og om du overhovedet har adgang til dens konfiguration.

nginx

Grænsen sættes i http-, server– eller location-blokken. Sæt den lidt højere end post_max_size:

server {
    # ...
    client_max_body_size 128m;
}

Test konfigurationen med nginx -t, og genindlæs med systemctl reload nginx. Står nginx foran Apache som reverse proxy, er det nginx-grænsen, der tæller først.

Apache

LimitRequestBody må stå i serverkonfigurationen, i en virtuel vært eller i .htaccess, hvis udbyderen tillader det. Værdien er i bytes:

# 128 MB
LimitRequestBody 134217728

LiteSpeed og delt hosting

På LiteSpeed sættes grænsen i serverens egen konfiguration, og på delt hosting er det udbyderen, der styrer den. Har du hævet PHP-grænserne, og får du stadig 413, er det her, du skal bede supporten om hjælp. Oplys den filstørrelse, du har brug for, og hvad filen skal bruges til.

5. Tjek proxy og firewall foran sitet

Kører domænet gennem Cloudflare (orange sky), afviser Cloudflare forespørgsler over planens grænse, uanset hvad serveren tillader. Svar-headeren server: cloudflare og en Cloudflare-fejlside afslører det. Løsningerne er:

• Upload filen ad en anden vej, fx via SFTP, og importér den bagefter (se næste afsnit).
• Brug et underdomæne til administration, der ikke går gennem proxyen (grå sky), hvis din opsætning tillader det – og beskyt det så på anden vis.
• Gør filen mindre. Det er ofte den reelle løsning.

En firewall eller et WAF-modul som ModSecurity kan have sin egen grænse for, hvor stor en forespørgsel må være. Den slår ofte til ved store formularer og importfiler. Svarer serveren 413 eller 403 kun på bestemte handlinger, så bed udbyderen kigge i firewall-loggen for netop det tidspunkt.

6. Når 413 rammer andet end billeder

Mediebiblioteket er det mest kendte sted, men samme grænse gælder alle forespørgsler med et stort indhold:

Situation	Hvorfor den rammer grænsen	Hvad du kan gøre
Upload af plugin- eller tema-zip	Premium-temaer med demoindhold kan fylde mange MB	Pak zip-filen ud, og upload mappen via SFTP til wp-content/plugins/ eller themes/
Import af indhold (WXR/XML eller CSV)	Eksportfiler fra store sites bliver hurtigt store	Del eksporten op i mindre filer, eller importér med WP-CLI
Gendannelse via backup-plugin	Hele sitet sendes som én forespørgsel	Upload arkivet via SFTP, og gendan derfra
Gem i blokeditoren	Meget lange indlæg med indlejrede data sendes som én JSON-forespørgsel	Del indholdet op, og fjern indlejrede base64-billeder
Formularer med vedhæftninger	Flere filer i én forespørgsel lægges sammen	Begræns antal og størrelse af filer i formularen

Gemmer du mange WooCommerce-variationer på én gang, og forsvinder nogle af dem, er det sjældent 413. Det er typisk PHP-grænsen max_input_vars, der skærer felter fra uden at give en fejlkode.

Upload uden om grænsen: SFTP og WP-CLI

Skal en enkelt stor fil op, og vil du ikke hæve grænserne permanent, så upload den via SFTP til en midlertidig mappe og importér den i mediebiblioteket med WP-CLI:

wp media import ~/upload/praesentation.pdf --title="Præsentation 2026"

Filen kopieres ind i wp-content/uploads/, får en post i mediebiblioteket, og WordPress laver miniaturer, hvis det er et billede. Ingen webserver- eller proxygrænse er involveret. Slet den midlertidige kopi bagefter.

Overvej om filen skal være så stor

En 413-fejl er ofte et symptom frem for et problem. Et billede på 12 MB hører sjældent hjemme på en hjemmeside – det gør siden langsom for alle besøgende, også dem der aldrig ser billedet i fuld størrelse.

Skalér billeder til den største størrelse, de faktisk vises i, og gem dem som WebP eller AVIF. Så forsvinder problemet af sig selv, og siden bliver hurtigere. Se billedoptimering i WordPress.

Skal du vise en stor videofil, hører den typisk hjemme hos en videotjeneste som YouTube eller Vimeo frem for i mediebiblioteket. Det skåner både lagerplads, båndbredde og upload-grænser.

Verificér, at det virker

• Upload den fil, der fejlede, igen – ikke bare en mindre testfil.
• Tjek i Netværk-fanen, at statuskoden nu er 200, og at filen står i mediebiblioteket.
• Åbn filen og et par af miniaturerne for at sikre, at WordPress nåede at behandle den.
• Tjek Webstedets helbred, så du ved, at PHP-værdierne faktisk er slået igennem.
• Kører sitet gennem Cloudflare, så test også fra et netværk, hvor proxyen er aktiv.

Virker uploaden ikke, og har du ændret flere ting, så sæt dem tilbage til de noterede værdier og tag ét lag ad gangen. Gav en php_value-linje i .htaccess en 500-fejl, så fjern linjen først.

Sådan undgår du den fremover

• Skalér billeder før upload – 2000 px bred er rigeligt til de fleste sider.
• Brug WebP eller AVIF frem for PNG til fotos.
• Læg video hos en videotjeneste i stedet for i mediebiblioteket.
• Sæt grænsen ét sted – i kontrolpanelet – og skriv værdien ned i din driftsdokumentation.
• Brug SFTP til de få store filer i stedet for at hæve grænsen for alle.

Har du WordPress hosting hos Hostious, kan dansk support hjælpe døgnet rundt med at finde ud af, hvilken grænse der rammer, og hvad der giver mening at sætte den til.

Læs også

• Hub: WordPress fejl og fejlfinding
• Hæv upload-grænsen i WordPress – det rigtige sted at gøre det
• HTTP-fejl ved upload af billeder – når fejlen ikke er en 413
• Billedoptimering i WordPress – mindre filer, færre problemer
• Hvad er SFTP? – sikker filadgang til store filer
• WordPress hosting hos Hostious – med dansk support døgnet rundt

Ofte stillede spørgsmål om 413 Request Entity Too Large

Hvorfor virker det for små filer, men ikke store?

Fordi grænsen er en størrelse, ikke en fejl i opsætningen. Alt under grænsen går igennem, alt over bliver afvist.

Er 413 og “filen overskrider upload_max_filesize” det samme?

Nej. Den anden besked kommer fra PHP og betyder, at forespørgslen nåede frem. En 413 betyder, at webserveren, en firewall eller en proxy afviste den, før PHP startede.

Kan Cloudflare give 413?

Ja. På Free og Pro er grænsen 100 MB pr. forespørgsel, på Business 200 MB. Er du over den, afvises uploadet, uanset hvad din server tillader.

Hvorfor viser Webstedets helbred en højere grænse, end jeg kan uploade?

Fordi WordPress kun kender PHP-grænserne. En lavere grænse i nginx, Apache, LiteSpeed, en firewall eller Cloudflare kan ikke ses fra WordPress, men afviser alligevel forespørgslen.