Die meisten Upload-Formulare melden jeden Fehlschlag mit demselben Satz. Hinter dieser einen Meldung stecken mindestens vier verschiedene Prüfungen, und jede verlangt eine andere Lösung.
Prüfung eins: die Byte-Grenze
Die häufigste Grenze und die einzige, an die überhaupt jemand denkt. Sie wird in Bytes gemessen, nicht in Megapixeln – ein klein wirkendes Bild direkt aus einem modernen Telefon kann sie also mühelos reißen.
Du löst das, indem du auf eine Zahl unterhalb der genannten Grenze komprimierst und nicht genau auf sie. Manche Systeme messen die kodierte Anfrage statt der Datei, und ein Upload, der unterwegs base64-kodiert wird, ist rund ein Drittel größer als die Datei auf der Festplatte. Ein paar Prozent unter der Grenze zu zielen kostet fast nichts und räumt die ganze Frage aus dem Weg.
Prüfung zwei: die Maßgrenze
Unabhängig von der Dateigröße und häufig nicht dokumentiert. Ein Formular kann ein Foto von höchstens 1200 Pixeln Breite verlangen, ganz gleich wie klein die Datei ist. Stärker zu komprimieren wird das nie erfüllen – du musst die Maße verkleinern. Nennt ein Formular eine Anzeigegröße, erzwingt es meistens auch ein Maximum in deren Nähe.
Prüfung drei: der MIME-Typ
Sorgfältige Server vertrauen der Dateiendung nicht; sie lesen die ersten Bytes und
erkennen das Format an seiner Signatur. Benennst du ein PNG in .jpg um, sieht ein
strenger Server weiterhin ein PNG, weil die Bytes das sagen.
Deshalb hilft Umwandeln und Umbenennen nicht. Deshalb kann auch eine Datei scheitern, die ein Grafikprogramm als „JPEG“ exportiert hat: Manche Exporter schreiben eine Variante, die die Bibliothek des Servers ablehnt.
Prüfung vier: Farbraum und Kodier-Variante
Seltener, aber real. CMYK-JPEGs, 16-Bit-PNGs und progressive JPEGs sind allesamt gültige Dateien, die manche älteren serverseitigen Bibliotheken rundweg ablehnen.
Neu zu kodieren behebt die Fälle, an die es herankommt. ToolZool dekodiert zu einfachen 8-Bit-Pixeln und schreibt standardmäßig Baseline-JPEG; ein 16-Bit-PNG kommt also als 8-Bit zurück und ein progressives JPEG als Baseline – beides genau die Varianten, die ein pingeliger Server am ehesten annimmt. Der unangenehme Fall ist das CMYK-JPEG: Es ist eine Datei aus dem Druckworkflow und nicht aus dem Web, und der zuverlässige Weg ist, es aus dem Programm, das es erzeugt hat, erneut als RGB zu exportieren.
Wie du sie auseinanderhältst
Probier ein bewusst winziges Testbild: ein paar Kilobyte, ein paar hundert Pixel, schlichtes Baseline-JPEG. Geht das durch, liegt das Problem an deiner Datei, und du weißt jetzt, an welcher Achse du drehen musst – fang beim Kompressor an, und wenn die Grenze eng ist, beschreibt ein 50-KB-Limit treffen die Reihenfolge, in der du etwas ändern solltest. Scheitert auch das Testbild, liegt es am Formular, an der Sitzung oder am Browser, und kein noch so gutes Neukodieren hilft.
