Wie hoch sind die Größenkosten von Base64 für eine JSON-API?

Etwa 33 % mehr als die Rohdatei, zuzüglich dessen, was das JSON-String-Escaping obendrauf packt (meist vernachlässigbar, da das Base64-Alphabet Zeichen vermeidet, die escaped werden müssten). Ein 3-MB-PDF wird zu rund 4 MB Base64-Text im JSON-Body.

Wann sollte ich multipart/form-data statt Base64 in JSON verwenden?

Bei großen Dateien oder jedem Upload, bei dem die Request-Größe zählt — multipart/form-data überträgt die Datei als Rohbytes ohne Kodierungs-Overhead und ist der Standardansatz für Upload-Endpunkte (auch bei einfachen HTML-Formularen). Base64-in-JSON ist üblicher bei kleinen Dateien, bei API-Clients, die nur JSON sprechen, oder bei Webhook-Payloads, die als ein einzelnes JSON-Objekt in sich geschlossen bleiben müssen.

Zählt Base64 in JSON gegen Request-Größenlimits?

Ja, und der 33-%-Overhead lässt das Limit schneller erreicht werden. Begrenzt ein API-Gateway oder Server den Request-Body etwa auf 10 MB, muss eine Base64-kodierte Datei roh unter rund 7,5 MB bleiben, um zu passen — das sollten Sie prüfen, bevor Sie annehmen, eine Datei „unter dem Limit“ werde nach der Kodierung tatsächlich erfolgreich hochgeladen.

Guide

Dateien als Base64 im JSON-Payload: Kosten und Alternativen

JSON hat keinen nativen Weg, um Binärdaten zu transportieren. Base64 ist der Workaround — und Workarounds haben ihren Preis.

By Buğra SözeriPublished September 25, 2026

Das Datenmodell von JSON — definiert in RFC 8259 — kennt keinen nativen Binärtyp. Jeder Wert ist entweder ein String, eine Zahl, ein Boolean, null, ein Objekt oder ein Array, und Strings müssen gültiger Unicode-Text sein. Die Rohbytes einer Datei können Bytefolgen enthalten, die überhaupt kein gültiger Text sind, sodass es keine Möglichkeit gibt, sie direkt in einen JSON-String zu packen. Base64 löst das, indem es die Binärdaten in ein eingeschränktes Alphabet aus 64 druckbaren ASCII-Zeichen umkodiert — sicher einbettbar in einen JSON-String, ein XML-Dokument oder eine URL, auf Kosten von rund 33 % mehr Bytes gegenüber der Originaldatei.

Wie der Payload tatsächlich aussieht

Ein typischer JSON-Body für Datei-Uploads verpackt die kodierten Daten in einem Feld neben Metadaten, die der Server zum Rekonstruieren der Datei benötigt:

{ "filename": "rechnung.pdf", "contentType": "application/pdf", "data": "JVBERi0xLjQK..." }

Der Server dekodiert das Feld data beim Empfang zurück in Rohbytes — genau der umgekehrte Schritt der Kodierung — und schreibt sie in den Speicher oder verarbeitet sie direkt. Dieses Muster ist bei Webhook-Payloads und API-Clients üblich, die nur JSON sprechen wollen, da es die zusätzliche Content-Type-Aushandlung vermeidet, die Multipart-Uploads erfordern.

Der Kompromiss: Größe und Request-Limits

Ansatz	Größen-Overhead	Am besten für
Base64 in JSON	~33 % größer	Kleine Dateien, reine JSON-Clients, Webhooks
multipart/form-data	Keiner (minimaler Boundary-Overhead)	Große Dateien, Standard-Upload-Endpunkte

Da die meisten API-Gateways, Load Balancer und Server-Frameworks eine maximale Request-Body-Größe erzwingen, frisst der 33-%-Overhead direkt davon, wie groß eine Datei tatsächlich hochgeladen werden kann. Ein auf 10 MB begrenztes Gateway deckelt Base64-in-JSON-Uploads effektiv bei rund 7,5 MB echtem Dateiinhalt — das sollten Sie anhand der dokumentierten Limits Ihres Anbieters prüfen, bevor Sie annehmen, eine Datei „unter dem Limit“ werde nach der Kodierung tatsächlich durchgehen.

Wann Sie auf Base64 ganz verzichten sollten

Bei allem, was über ein paar Megabyte hinausgeht, oder bei jedem Endpunkt, bei dem Request-Größe oder Upload-Geschwindigkeit wirklich zählen, ist multipart/form-data das bessere Werkzeug: Es sendet die Rohbytes der Datei mit nur einem kleinen Boundary-Marker-Overhead, ohne die 33-%-Abgabe. Das nutzen auch einfache HTML-Formulare mit <input type="file"> nativ über die FormData-API. Greifen Sie gezielt zu Base64-in-JSON, wenn der Client nur JSON senden kann, die Datei klein ist oder der Payload als ein einziges, in sich geschlossenes JSON-Objekt bleiben muss — nicht als Standard für jeden Upload.

Frequently asked questions

Warum kann ich Binärdaten nicht einfach direkt in JSON einfügen?: Die JSON-Grammatik definiert nur Strings, Zahlen, Booleans, null, Objekte und Arrays — Strings müssen gültiger Unicode-Text sein. Rohe Binärbytes können Bytefolgen enthalten, die überhaupt kein gültiger Text sind, lassen sich also nicht ohne vorherige Umwandlung in eine textsichere Darstellung in einen JSON-String einbetten — genau das leistet Base64.
Wie hoch sind die Größenkosten von Base64 für eine JSON-API?: Etwa 33 % mehr als die Rohdatei, zuzüglich dessen, was das JSON-String-Escaping obendrauf packt (meist vernachlässigbar, da das Base64-Alphabet Zeichen vermeidet, die escaped werden müssten). Ein 3-MB-PDF wird zu rund 4 MB Base64-Text im JSON-Body.
Wann sollte ich multipart/form-data statt Base64 in JSON verwenden?: Bei großen Dateien oder jedem Upload, bei dem die Request-Größe zählt — multipart/form-data überträgt die Datei als Rohbytes ohne Kodierungs-Overhead und ist der Standardansatz für Upload-Endpunkte (auch bei einfachen HTML-Formularen). Base64-in-JSON ist üblicher bei kleinen Dateien, bei API-Clients, die nur JSON sprechen, oder bei Webhook-Payloads, die als ein einzelnes JSON-Objekt in sich geschlossen bleiben müssen.
Zählt Base64 in JSON gegen Request-Größenlimits?: Ja, und der 33-%-Overhead lässt das Limit schneller erreicht werden. Begrenzt ein API-Gateway oder Server den Request-Body etwa auf 10 MB, muss eine Base64-kodierte Datei roh unter rund 7,5 MB bleiben, um zu passen — das sollten Sie prüfen, bevor Sie annehmen, eine Datei „unter dem Limit“ werde nach der Kodierung tatsächlich erfolgreich hochgeladen.

Sources & references

Authoritative references cited by this piece. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.

RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format — Die JSON-Spezifikation, die nur textbasierte String-Werte definiert — kein nativer Binärtyp(as of 2026-09-25)
RFC 4648 — The Base16, Base32, and Base64 Data Encodings — Die Kodierung, mit der Binärdaten als JSON-sicherer String dargestellt werden(as of 2026-09-25)
MDN — Using FormData objects — Die Multipart-Alternative, die den Base64-Overhead bei Datei-Uploads vermeidet(as of 2026-09-25)

Published September 25, 2026