HTTP-fejl ved upload af billeder – sådan finder du årsagen

Kort svar: “HTTP-fejl.” ved billedupload er en samlebesked: noget på serveren afbrød uploaden eller billedbehandlingen bagefter. Find mønsteret først – rammer det kun store billeder, én bestemt fil eller alle uploads? Store billeder peger på hukommelse og billedbehandling, enkelte filer på filnavn og format, og alle uploads på PHP-grænser, rettigheder, fuld disk eller en sikkerhedsregel. Ret det led, mønsteret udpeger, i stedet for at prøve ti råd i blinde.

Fagligt gennemgået: 2. oktober 2026

Uploaden kører til 100 %, og så står der bare “HTTP-fejl.” i mediebiblioteket. Beskeden er bevidst generisk: browseren fik et svar, den ikke kunne bruge, men WordPress ved ikke hvorfor. Årsagen ligger næsten altid på serveren – og den kan findes systematisk.

Det vigtigste at forstå er, at en upload består af to faser. Først sendes filen til serveren og gemmes. Derefter laver WordPress thumbnails og skalerede størrelser af billedet. Begge faser kan fejle, og de fejler af forskellige grunde. Når statuslinjen når 100 %, er filen typisk kommet frem – fejlen opstår så i billedbehandlingen.

Før du ændrer noget: Notér tidspunktet for den fejlende upload, og gem en kopi af den fil, der fejlede. Ret én ting ad gangen, og test med samme fil bagefter – ellers ved du ikke, hvilken ændring der hjalp. Ændrer du i wp-config.php, .htaccess eller PHP-indstillinger, så tag en kopi af filen eller værdien først.

1. Find mønsteret

Upload tre testfiler: et lille billede (under 500 KB), en kopi af det billede, der fejlede, og det fejlende billede omdøbt til test.jpg. Resultatet indsnævrer årsagen:

Mønster	Sandsynligt led	Gå til
Kun store billeder fejler	Hukommelse, billedbehandling eller upload-grænser	Trin 3 og 4
Kun én bestemt fil fejler	Filnavn, format eller defekt fil	Trin 5
Alle uploads fejler	Grænser, rettigheder, disk eller sikkerhedsregler	Trin 3 og 6
Fejler kun nogle gange	Timeout eller hukommelse under belastning	Trin 4 og 6
Fejler kun for én bruger	Rolle, browserudvidelse eller plugin med brugerspecifik logik	Trin 7

2. Læs det rigtige svar i browseren

“HTTP-fejl.” skjuler den egentlige statuskode. Åbn browserens udviklerværktøjer (F12), vælg fanen Netværk, og upload filen igen. Find requesten til async-upload.php, og kig på statuskoden og svarets indhold:

Svar fra async-upload.php	Hvad det betyder
500 eller tomt svar	PHP stoppede undervejs – typisk hukommelse eller en fatal fejl. Tjek PHP-loggen.
502, 503 eller 504	PHP-processen blev afbrudt eller svarede ikke i tide – timeout eller ressourcegrænse.
413	Filen er større end en grænse i webserver, proxy eller Cloudflare.
403	En sikkerhedsregel (firewall, ModSecurity, sikkerhedsplugin) afviste requesten.
200 med HTML eller PHP-advarsler i svaret	Et plugin eller tema skriver tekst ud, som ødelægger WordPress’ JSON-svar.

Statuskoden alene sparer dig ofte for halvdelen af fejlfindingen. En 403 skal ikke løses med mere hukommelse, og en 500 skyldes sjældent filnavnet.

3. Tjek de tre grænser

Tre PHP-indstillinger skal alle være store nok: upload_max_filesize, post_max_size og memory_limit. Du kan se de aktuelle værdier under Værktøjer → Webstedstilstand → Info → Server og Mediehåndtering – eller i terminalen:

wp eval 'echo ini_get("upload_max_filesize"), " / ", ini_get("post_max_size"), " / ", ini_get("memory_limit"), PHP_EOL;'

Bemærk, at WP-CLI kan køre med en anden PHP-konfiguration end webserveren. Er du i tvivl, så stol på tallene i Webstedstilstand, som kommer fra den PHP, der faktisk behandler uploaden.

Er grænserne for lave, hæver du dem det rigtige sted – se guiden hæv upload-grænsen i WordPress. Husk at post_max_size skal være større end upload_max_filesize, ellers gælder den mindste. WordPress har desuden to hukommelseskonstanter: WP_MEMORY_LIMIT for forsiden og WP_MAX_MEMORY_LIMIT for administrationen, som også bruges, når billeder behandles. Ingen af dem kan gå over den grænse, serveren tillader.

4. Billedbehandlingen æder hukommelsen

Efter selve uploaden genererer WordPress thumbnails og skalerede størrelser. Her gælder billedets dimensioner mere end filstørrelsen: et 8000×6000-pixel foto skal pakkes ud i rå pixels i hukommelsen, uanset at JPEG-filen kun fylder 4 MB. Med fire byte pr. pixel er det omkring 190 MB for én ukomprimeret kopi – før billedbiblioteket har lavet en eneste skaleret version. Løber PHP tør midt i behandlingen, får browseren et tomt svar – og du får “HTTP-fejl.”

• Skaler billeder til maksimalt ca. 2560 pixels på den længste side før upload – større visninger bruger de færreste sites alligevel.
• Rammer fejlen kun ved store filer, så tjek loggen for “Allowed memory size exhausted” – og følg i så fald hukommelsesguiden.
• Tager behandlingen for lang tid på mange størrelser, kan også maximum execution time afbryde den.
• Har temaet og dine plugins registreret mange ekstra billedstørrelser, laver WordPress én fil pr. størrelse. Færre størrelser betyder mindre arbejde pr. upload.

Imagick eller GD

WordPress bruger Imagick, hvis det er installeret, og ellers GD. Hvilket bibliotek der er aktivt, står under Webstedstilstand → Info → Mediehåndtering sammen med Imagicks ressourcegrænser. Imagick kan på nogle servere løbe ind i egne grænser for hukommelse eller tråde, selvom PHP-grænsen ser fin ud. Som test kan du få WordPress til at foretrække GD med et lille mu-plugin:

<?php
// wp-content/mu-plugins/test-gd-foerst.php – kun til test
add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
} );

Forsvinder fejlen med GD, ligger problemet i Imagick-opsætningen på serveren – det er en sag for hostingens support. Fjern filen igen bagefter, når årsagen er fundet, så du ikke ender med en midlertidig test som permanent løsning.

Grænsen på 2560 pixels

Siden WordPress 5.3 skalerer WordPress automatisk billeder over 2560 pixels ned og gemmer originalen ved siden af med “-scaled” i filnavnet. Det beskytter visningen, men ikke uploaden: hele originalen skal stadig pakkes ud én gang. Derfor hjælper det mere at skalere billedet ned på din egen computer end at stole på den automatiske skalering. Grænsen kan ændres med filteret big_image_size_threshold, men at slå den fra gør kun billedbehandlingen tungere.

5. Filnavne og formater

Danske bogstaver er ikke problemet – WordPress omskriver selv æ, ø og å i filnavne. Ballade kommer derimod fra apostroffer, anførselstegn, procenttegn og emojis i filnavnet samt fra filer, der ikke er det, endelsen påstår (en HEIC-fil omdøbt til .jpg, en defekt eksport). Omdøb til små bogstaver og bindestreger, og gem billedet i et nyt format i et billedprogram, hvis den enkelte fil bliver ved med at fejle.

• HEIC fra iPhone: nyere WordPress-versioner kan konvertere HEIC til JPEG ved upload, men kun hvis serverens Imagick understøtter formatet. Ellers afvises filen eller fejler i behandlingen. Eksportér som JPEG på telefonen, eller vælg “Mest kompatibel” i kameraets formatindstilling.
• WebP og AVIF: WordPress accepterer formaterne, men serverens billedbibliotek skal kunne læse dem for at lave thumbnails. Mangler understøttelsen, beder WordPress dig konvertere til JPEG eller PNG.
• CMYK og meget store PNG-filer: billeder fra trykkeri eller designprogrammer kan være i CMYK eller have enorme dimensioner. Gem dem som RGB-JPEG i webstørrelse før upload.
• Defekte filer: kan billedet ikke åbnes i et almindeligt billedprogram, kan serveren heller ikke behandle det.

6. Sikkerhedslag og midlertidige mapper

Fejler alle uploads, ligger årsagen typisk under WordPress:

• Firewall/ModSecurity: en regel afviser POST-requests til async-upload. Tjek svarkoden i browserens Netværk-fane – 403 peger på en sikkerhedsregel, ikke på WordPress. Hostingens support kan finde den konkrete regel i loggen ud fra tidspunktet.
• Skriverettigheder: kan WordPress ikke skrive i uploads-mappen, får du ofte også fejlen “could not create directory” – se den guide og filrettigheder 644/755.
• Fuld disk eller fuld tmp-mappe: uploaden lander først i en midlertidig mappe. Er den fuld, eller er diskkvoten brugt op, fejler alt. Tjek diskforbruget i kontrolpanelet – gamle backups i webroden og store logfiler er typiske syndere.
• Cloudflare eller proxy: en grænse på request-størrelse giver 413 Request Entity Too Large – samme symptom, anden fejlkode.
• Timeout i webserver eller proxy: en langsom forbindelse eller tung billedbehandling kan ramme en timeout før PHP. Det giver typisk 502 eller 504 i Netværk-fanen.

7. Udeluk plugins og tema

Billedoptimering, sikkerhed og watermark-plugins hænger sig på uploaden og kan få den til at fejle. Det samme kan et plugin, der skriver PHP-advarsler ud i svaret. Test derfor på en staging-kopi eller i et roligt tidsrum:

1. Slå billedoptimerings- og sikkerhedsplugins fra, og upload den samme fil igen.
2. Virker det, så aktivér plugins ét ad gangen, indtil fejlen kommer tilbage.
3. Virker det stadig ikke, så skift midlertidigt til et standardtema på staging og test igen.

Slå samtidig fejllogning til, så du kan se, hvad der sker under uploaden. Tilføj dette i wp-config.php over linjen “That’s all, stop editing”, og fjern det igen, når du er færdig:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Fejlene havner i wp-content/debug.log. Med WP_DEBUG_DISPLAY sat til false vises de ikke for besøgende og ødelægger heller ikke uploadens svar.

8. Verificér rettelsen

Rettelsen holder, når det billede, der fejlede, nu uploader og får genereret alle størrelser (tjek med “Rediger billede” eller i uploads-mappen), når et billede i fuld størrelse også går igennem, og når loggen ikke får nye fejllinjer under uploaden. Er der billeder fra fejlperioden, som mangler størrelser, kan du lave dem igen med WP-CLI:

wp media regenerate --only-missing --yes

Står du stadig med fejlen efter trin 7, så gem svarkoden fra Netværk-fanen og tidspunktet – så kan Hostious-supporten slå den konkrete request op i serverloggen.

Forebyg fejlen fremover

• Lav en fast rutine: billeder skaleres til webstørrelse og komprimeres, før de uploades.
• Brug filnavne med små bogstaver, tal og bindestreger – det hjælper også på billed-SEO.
• Hold øje med diskforbruget, så uploads ikke stopper, når kvoten er brugt.
• Ryd op i billedstørrelser fra gamle temaer og plugins, du ikke længere bruger.

Rækkefølgen for at optimere billeder, før du installerer et plugin til det, står i guiden om billedoptimering i WordPress.

Læs også

• Hub: WordPress fejl og fejlfinding
• Hæv upload-grænsen i WordPress
• 413 Request Entity Too Large
• Allowed memory size exhausted
• Billeder vises ikke efter en flytning
• WordPress hosting hos Hostious – hosting hvor supporten kender WordPress

Ofte stillede spørgsmål om HTTP-fejl ved upload

Hvorfor fejler kun store billeder?

Fordi billedbehandlingen pakker billedet ud i rå pixels. Dimensionerne bestemmer hukommelsesforbruget – ikke filstørrelsen. Skaler til ca. 2560 pixels på længste side før upload, så forsvinder problemet oftest.

Hjælper det at skifte browser?

Sjældent. Fejlen er serverens svar på uploaden, ikke browserens. Virker det pludselig i en anden browser, var det formentlig en tilfældighed – fx mindre belastning i det øjeblik.

Hvad er en fornuftig maksstørrelse for billeder?

Cirka 2560 pixels på den længste side og gerne under 1 MB efter komprimering. WordPress skalerer selv billeder over 2560 pixels ned og gemmer originalen – så store uploads giver dobbelt diskforbrug uden visuel gevinst.

Hvordan ser jeg den rigtige fejlkode bag “HTTP-fejl.”?

Åbn browserens udviklerværktøjer, vælg fanen Netværk, og upload filen igen. Requesten til async-upload.php viser statuskoden: 500 peger på PHP, 413 på en størrelsesgrænse og 403 på en sikkerhedsregel.