Maximale Upload Dateigröße in WordPress erhöhen

Du ziehst ein 60MB Video in die WordPress Mediathek, wartest ein paar Sekunden, und bekommst eine von drei Fehlermeldungen zurück: "Die hochgeladene Datei überschreitet die Anweisung upload_max_filesize in php.ini", "413 Request Entity Too Large", oder schlicht "HTTP Fehler" ohne weitere Erklärung. Die Lösung ist fast immer, das maximale Upload Limit hochzusetzen, aber wie bei den meisten WordPress Limit Themen gibt es nicht nur ein Limit. Es gibt vier, sie liegen an verschiedenen Stellen, und das niedrigste gewinnt. Diese Anleitung erklärt, welches Limit für welche Fehlermeldung verantwortlich ist und wie du jedes davon auf den verschiedenen Hosting Setups sauber hochsetzt.

Welches Limit ist für welche Fehlermeldung verantwortlich?

Vier separate Einstellungen können einen Upload blockieren. Wenn du weißt, welche dich erwischt hat, sparst du dir viel Probieren.

PHP upload_max_filesize. Die harte Obergrenze für die Größe einer einzelnen hochgeladenen Datei. Default auf den meisten Hostern liegt zwischen 2M und 64M. Wenn deine Datei diese Grenze überschreitet, zeigt WordPress die explizite Meldung "Die hochgeladene Datei überschreitet die Anweisung upload_max_filesize".
PHP post_max_size. Die maximale Größe des gesamten POST Requests, inklusive Datei und allen anderen Formularfeldern. Muss mindestens so groß sein wie upload_max_filesize; sonst scheitert der Upload still, bevor WordPress ihn überhaupt sieht. Default liegt typisch bei 8M bis 64M.
PHP max_execution_time und max_input_time. Zeitlimits in Sekunden. Ein großer Upload über eine langsame Verbindung kann ins Zeitlimit laufen, bevor die Datei fertig übertragen ist, auch wenn die Größenlimits passen. Default liegt meist bei 30 bis 60 Sekunden. Symptom: Upload startet, Fortschrittsbalken kommt bis 80%, dann scheitert es mit "HTTP Fehler".
Webserver Body Limit. nginx hat eine client_max_body_size Direktive (Default 1M, schmerzhaft niedrig für Medien Uploads). Apache deckelt das standardmäßig selten, aber Reverse Proxies, Load Balancer und CDNs (vor allem Cloudflare, mit 100M auf Free, 200M auf Pro, 500M auf Business) setzen jeweils eigene Obergrenzen. Symptom: eine "413 Request Entity Too Large" Seite, die gar nicht wie WordPress aussieht, weil WordPress den Request nie bekommen hat.

Die effektive maximale Upload Größe ist das Minimum aller vier Werte. WordPress zeigt dieses effektive Limit direkt auf der Upload Seite: in Medien, Datei hinzufügen erscheint unten am Upload Bereich der Hinweis "Maximale Upload Dateigröße".

Wie viel brauchst du tatsächlich?

Praktisches Mental Model:

32M. Reicht für typische Bilder, PDFs und kleine Audiodateien. Default auf konservativen Shared Hostern.
64M. Komfortabel für die meisten redaktionellen Seiten. Verkraftet Foto Serien aus aktuellen Kameras, größere PDFs und kurze Video Clips.
128M bis 256M. Der richtige Bereich für Seiten, die regelmäßig Video, große PSD Dateien, Design Assets oder Theme und Plugin Zips für eine selbst gehostete Installation hochladen.
Über 256M. Vor allem für videolastige Seiten relevant, Podcast Feeds mit großen Audiodateien oder Kursplattformen mit herunterladbarem Lehrmaterial. Lohnt sich, kurz zu hinterfragen, ob die Datei wirklich auf dem WordPress Server liegen muss, oder ob ein Dienst wie Vimeo, YouTube, Bunny Stream oder ein eigener S3 Bucket nicht der bessere Ort ist. WordPress ist nicht darauf optimiert, große Mediendateien in Skalierung auszuliefern.

Ein Detail, das oft übersehen wird: WordPress hat auch ein eigenes internes Limit. Standardmäßig setzt es kein Limit über das hinaus, was PHP zulässt, also sind auf den meisten Hostern allein die PHP Werte ausschlaggebend. Der Filter upload_size_limit existiert, falls du eine projektspezifische Obergrenze setzen willst (sinnvoll im Multisite, um verschiedenen Rollen verschiedene Limits zu geben), kann das effektive Limit aber nur senken, nie über das PHP Limit hinaus anheben.

Option 1: PHP Limits per Hoster Panel hochsetzen

Fast immer der richtige Startpunkt. Die meisten Hoster im Jahr 2026 bieten die relevanten Einstellungen im Dashboard an, und Änderungen greifen binnen Sekunden.

cPanel (IONOS, Hostinger, viele Reseller)

Im MultiPHP INI Editor die Domain auswählen und folgende Werte anpassen:

upload_max_filesize auf den Zielwert (z.B. 128M)
post_max_size auf denselben oder höheren Wert (z.B. 128M)
max_execution_time auf mindestens 300 Sekunden für große Dateien
max_input_time auf denselben Wert
memory_limit auf 256M oder höher (Uploads werden während der Verarbeitung kurzzeitig in den Speicher geladen)

Speichern. Die Änderung ist sofort aktiv.

Plesk (All Inkl, DomainFactory, viele deutsche Hoster)

Die Domain in Plesk öffnen, auf PHP Einstellungen klicken, zum Abschnitt "Performance und Sicherheitseinstellungen" scrollen. Die Felder sind dieselben wie bei cPanel. Speichern, und die Werte gelten ab dem nächsten Request.

Managed WordPress Hosting (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Diese Hoster liefern fast immer schon vernünftige Defaults aus (typisch 64M bis 128M). Wenn das Limit für deinen Anwendungsfall trotzdem zu niedrig ist, gibt es im Dashboard meistens einen Slider oder ein Eingabefeld. Einige Hoster (WP Engine, Pressable) deckeln das absolute Maximum und brauchen ab einer bestimmten Größe ein Support Ticket, weil deren Upload Pipeline Dateien gegen ein CDN vorvalidiert. Solche Tickets werden in der Regel binnen Stunden beantwortet, nicht Tagen.

Option 2: .user.ini im WordPress Wurzelverzeichnis

Wenn dein Hoster PHP über FastCGI oder PHP FPM ausliefert (faktisch jeder moderne Hoster), aber kein Einstellungs Panel anbietet, kannst du eine .user.ini Datei direkt ins WordPress Wurzelverzeichnis legen:

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

PHP zieht die .user.ini automatisch. Einzige Eigenheit: ein Standard Cache von fünf Minuten (gesteuert über user_ini.cache_ttl), Änderungen greifen also nicht zwingend beim allernächsten Request.

Verifizieren über die WordPress Site Health: Werkzeuge, Website Zustand, Bericht, Server zeigt das aktive upload_max_filesize und post_max_size. Wenn die Werte nach zehn Minuten immer noch den alten Defaults entsprechen, unterstützt der Hoster entweder .user.ini nicht oder fährt PHP in einem Modus, der die Datei ignoriert. Dann weiter mit Option 3.

Option 3: php.ini auf einem selbst verwalteten Server

Auf einem VPS oder Root Server, auf dem du PHP selbst kontrollierst, direkt die aktive php.ini bearbeiten. Den Pfad findest du mit php --ini auf der Kommandozeile. Er variiert je nach Distribution und PHP Version (typisch /etc/php/8.2/fpm/php.ini auf Debian oder Ubuntu, /etc/php.ini auf CentOS oder RHEL).

Dieselben fünf Werte wie in Option 1 anpassen, dann PHP FPM neu laden:

sudo systemctl reload php8.2-fpm

(Versionsnummer an deine Installation anpassen.) Auf Apache mit mod_php stattdessen Apache neu starten. Die Änderung greift sofort, kein weiterer Schritt nötig.

Option 4: nginx client_max_body_size

Das ist die Falle, in die viele auf selbst verwaltetem nginx tappen. PHP kann auf 1GB Uploads konfiguriert sein, aber wenn nginx mit dem Default von 1M gedeckelt ist, kommt der Upload überhaupt nicht bei PHP an. Der Browser zeigt dann einen generischen "413 Request Entity Too Large" Fehler, oft ohne Hinweis darauf, dass nginx die Bremse ist.

Die Direktive in den server Block deiner Seite eintragen, oder global in den http Block der nginx.conf:

client_max_body_size 128M;

Mit sudo nginx -t && sudo systemctl reload nginx nginx neu laden. Der Wert sollte mindestens deinem PHP post_max_size entsprechen oder höher liegen. Es schadet nicht, ihn etwas höher zu setzen; das tatsächliche Limit ist weiterhin PHP.

Option 5: Apache mit .htaccess (Legacy)

Auf älteren Apache Setups mit mod_php (auf modernem Hosting selten, auf Legacy Servern noch häufig) kannst du die PHP Direktiven direkt in die .htaccess im WordPress Wurzelverzeichnis schreiben:

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

Wenn dein Hoster PHP über FastCGI oder PHP FPM ausliefert (also faktisch jeder moderne Hoster), wirft diese Direktive einen 500er Fehler oder wird still ignoriert. Dann .user.ini aus Option 2 nutzen.

Option 6: Wenn das Limit am CDN oder Proxy hängt

Wenn du PHP und Webserver auf 256M Uploads konfiguriert hast, der Upload aber trotzdem bei beispielsweise 100M scheitert, sitzt der Engpass irgendwo vor dem WordPress Server. Häufige Verdächtige:

Cloudflare deckelt die Body Size pro Tarif: 100M auf Free, 200M auf Pro, 500M auf Business, 500M auf Enterprise (auf Anfrage höher). Für größere Uploads entweder den Tarif aufstocken, den WordPress Admin per Page Rule auf "DNS only" für /wp-admin/ aus dem Proxy ausnehmen, oder eine eigene Subdomain nutzen, die Cloudflare für Uploads umgeht.
Cloudways hat eine Varnish Schicht mit standardmäßig niedrigem Body Limit. Im Dashboard unter "Application Settings, Server Configurations" steuerbar.
Reverse Proxies vor nginx (HAProxy, Traefik) haben jeweils eigene Body Limits, die in den jeweiligen Config Dateien angehoben werden müssen.
Manche Firewalls und Security Plugins auf WAF Ebene (Sucuri, Wordfence Premium mit Cloud WAF) deckeln Upload Größen standardmäßig. In deren Einstellungs Panel gibt es eine separate Option dafür.

Diagnose Trick: den Upload vom Server selbst aus mit curl und einer lokalen Datei testen. Wenn der Upload lokal funktioniert, aber über die öffentliche URL scheitert, liegt das Limit auf einer Proxy oder CDN Schicht, nicht in PHP.

So prüfst du, ob die neuen Limits aktiv sind

Im WordPress Admin Werkzeuge, Website Zustand, Bericht öffnen.
Den Abschnitt Server ausklappen. Such nach upload_max_filesize, post_max_size, max_execution_time und memory_limit. Alle sollten die neuen Werte zeigen.
Schnellere Prüfung: Medien, Datei hinzufügen öffnen. Die Zeile "Maximale Upload Dateigröße" unten am Upload Bereich sollte das neue effektive Limit anzeigen.
Den eigentlichen Upload, der das Problem ausgelöst hat, nochmal probieren. Wenn er weiterhin scheitert, genau auf die Fehlermeldung achten; sie verrät, welches der vier Limits noch zu niedrig ist.

Was tun, wenn die Datei wirklich zu groß für einen HTTP Upload ist?

Oberhalb von 500M bis 1GB werden Browser Uploads unabhängig von Server Einstellungen unpraktikabel. Die TCP Verbindung wird instabil, dazwischenliegende Proxies laufen in Timeouts, und ein einziger Netzwerk Hänger bedeutet "von vorne anfangen". Zwei vernünftigere Alternativen:

Per SFTP hochladen und in WordPress importieren. Die Datei direkt per SFTP nach wp-content/uploads/JAHR/MONAT/ ablegen, dann mit einem Plugin wie Add From Server oder Media Sync in der Mediathek registrieren. WordPress erzeugt Metadaten und Thumbnails so, als hättest du normal hochgeladen.
Externe Mediendienste. Speziell für Video sind Vimeo, Bunny Stream, Cloudflare Stream und YouTube für Hosting und Adaptive Streaming deutlich besser geeignet als WordPress Core. Die meisten modernen Themes und Page Builder binden diese Dienste nativ ein, inklusive automatisch generierter Thumbnails. Selbe Logik für Audio (Soundcloud, Spotify for Podcasters) und große Datei Downloads (S3 mit CloudFront oder Bunny CDN davor).

Ein 5GB Roh Video auf Shared WordPress Hosting zu legen und direkt auszuliefern ist technisch möglich, aber selten der richtige Weg. Bandbreitenkosten, fehlendes Adaptive Bitrate und die Belastung eines einzelnen PHP Workers pro gleichzeitigem Zuschauer sprechen alle für dediziertes Media Hosting.

Häufige Fehler

upload_max_filesize hochsetzen, ohne post_max_size mit zu erhöhen. Der Upload scheitert still, weil der gesamte POST Request den niedrigeren der beiden Werte reißt. Immer beide zusammen ändern.
Absurd hohe Werte "vorsichtshalber" setzen. Ein 4G Upload Limit auf einem Server mit 4GB RAM ist ein Denial of Service Vektor. PHP lädt Teile des Uploads während der Verarbeitung in den Speicher. Einen Wert wählen, der zum tatsächlichen Bedarf plus etwas Spielraum passt.
max_execution_time vergessen. Ein 500MB Upload über eine 10 Mbit/s Verbindung dauert rund sieben Minuten. Wenn max_execution_time auf den Default von 30 Sekunden steht, bricht der Request mitten im Upload ab, egal wie hoch die Größenlimits sind.
Falsche php.ini bearbeitet. Häufiger Fehler auf Systemen mit mehreren installierten PHP Versionen (z.B. 7.4 und 8.2 beide vorhanden, aber nur eine aktiv). Der php --ini Aufruf auf der Kommandozeile zeigt eventuell auf eine andere php.ini als die, die PHP FPM für den Webserver nutzt. Site Health ist die verlässliche Quelle.

In den meisten Fällen lösen zwei Minuten im Hoster Panel mit dem Anheben von fünf Werten auf vernünftige Defaults das Problem dauerhaft. Die Fehlermeldungen rund um Upload Limits sind unglücklich formuliert und klingen nach obskuren technischen Problemen, der eigentliche Fix ist aber mechanisch und gut dokumentiert. Sind die Limits einmal auf deinen tatsächlichen Bedarf zugeschnitten, ist das eines der WordPress Themen, das nie wieder hochkommt.