Online-Base64-Decoder

1. 1

   Base64 einfügen

   Füge den String in das Eingabefeld ein. Zeilenumbrüche, fehlende Auffüllzeichen und base64url-Zeichen werden alle verarbeitet, und ein Data-URI, PEM-Block oder JWT kann komplett eingefügt werden — die Hülle wird erkannt und für dich entfernt.

2. 2

   Ergebnis lesen

   Bis 256 KB erscheint die Ausgabe beim Tippen; größere Eingaben werden mit „Dekodieren“ verarbeitet. Das Panel nennt das erkannte Format, den in den Bytes gefundenen Dateityp und den Zeichensatz, mit dem Text dargestellt wird.

3. 3

   Nachjustieren, falls die Erkennung danebenlag

   Wechsle zwischen Text-, Hex- und ASCII-Ansicht, wähle einen bestimmten Zeichensatz, wenn die Erkennung Ersatzzeichen erzeugt hat, oder schalte den strengen Modus ein, damit fehlerhafte Eingaben abgelehnt statt repariert werden.

4. 4

   Kopieren oder herunterladen

   Kopiere den Text oder lade die Nutzdaten mit der Endung herunter, die ihre eigenen Bytes vorgeben — ein dekodiertes PNG wird als .png gespeichert, nicht als .bin. Alles läuft auf deinem Gerät, nichts wird hochgeladen.

Fünf Einstellungen, und jede davon existiert, weil echte Nutzdaten sie gebraucht haben. Nichts davon steckt hinter einem Bezahltarif — ein Decoder, der das Dekodieren zurückhält, ist nicht begrenzt, sondern kaputt.

Eingabeformat

Lass das auf Auto und füge irgendetwas ein. Das Tool prüft der Reihe nach auf ein Data-URI-Präfix, einen OpenPGP-Armor-Block, einen PEM-Header und ein dreiteiliges JWT und behandelt die Eingabe sonst als reine Nutzdaten. Ein Format ausdrücklich zu wählen macht daraus eine Behauptung: Wählst du PEM und die Eingabe hat keine BEGIN-Zeile, wird dir das gesagt, statt dass etwas anderes dekodiert wird. Standard oder URL-sicher legt zusätzlich das Alphabet fest, sodass im strengen Modus Nutzdaten mit dem anderen Alphabet genau an der Stelle abgelehnt werden, an der sie abweichen.

Strenger Modus

Standardmäßig aus, denn die alltägliche Aufgabe ist, einen String zu lesen, den dir jemand geschickt hat, und ihn wegen eines fehlenden = abzulehnen hilft niemandem. Eingeschaltet werden vier Dinge zu Fehlern statt zu Reparaturen: Leerraum außerhalb eines umbrochenen Formats, fehlende oder falsche Auffüllung, ein gemischtes Alphabet und eine Schlussgruppe, deren ungenutzte Bits nicht null sind. Letzteres ist besonders erwähnenswert — es hat weiter unten einen eigenen Abschnitt, und kein anderer Decoder im Web meldet es.

Eingabe aufteilen

Ein Mechanismus, zwei Anwendungen. „Jede Zeile“ dekodiert eine Liste unabhängiger Nutzdaten einzeln und zeigt sie als getrennte Ergebnisse — genau das, was man will, wenn eine Logdatei oder Datenbankspalte einen Base64-Wert pro Zeile enthält. „JWT-Segmente“ teilt stattdessen an den Punkten, sodass Header und Payload eines Tokens jeweils für sich dekodieren und eine Signatur, die kein lesbarer Text ist, den Rest nicht verdirbt. Auto wählt das Zweite, wenn die Eingabe ein JWT ist, und lässt alles andere in Ruhe.

Ergebnis anzeigen als

Auto zeigt Text bei Text-Nutzdaten und einen Hex-Dump bei allem anderen — anhand dessen, was die Bytes tatsächlich sind, nicht anhand dessen, ob ein Textdecoder irgendetwas erzeugt hat. Du kannst das überstimmen: Hex ist die richtige Ansicht für binäre Nutzdaten, die du untersuchst, druckbares ASCII hilft beim Aufspüren eingebetteter Zeichenketten in einer Binärdatei, und Text zu erzwingen ist der Weg, Nutzdaten zu prüfen, die die Erkennung falsch eingeordnet hat. Das Umschalten ist sofort, weil bereits dekodierte Bytes neu dargestellt werden.

Zeichensatz

Auto liest zuerst eine Bytereihenfolge-Markierung, dann einen von einem Data-URI angegebenen Zeichensatz, prüft dann, ob die Bytes gültiges UTF-8 sind, und fällt sonst als ausdrücklich benannte Vermutung auf Windows-1252 zurück. Enthält das Ergebnis Ersatzzeichen, nennt das Panel deren Anzahl, und die richtige Wahl aus der Liste behebt das, ohne das Base64 erneut zu dekodieren.

Base64 ist eine Kodierung, kommt aber in mindestens sieben verschiedenen Hüllen an. Ein Decoder, der nur reine Nutzdaten akzeptiert, lehnt das meiste ab, was tatsächlich in der Zwischenablage liegt.

• Standard — das Alphabet aus RFC 4648 — A–Z, a–z, 0–9, + und /, aufgefüllt mit =. Was die meisten Encoder ausgeben.
• URL-sicher (base64url) — dasselbe, mit - und _ statt + und /, damit der String eine URL oder einen Dateinamen übersteht. Meist ohne Auffüllung. Wird ohne Einstellung erkannt und dekodiert.
• MIME — Standard-Base64, auf 76 Spalten umbrochen, wie es E-Mail-Bodies verwenden. Die Zeilenumbrüche werden entfernt; im strengen Modus sind sie der einzige zulässige Leerraum, weil das Format über sie definiert ist.
• PEM — Nutzdaten zwischen -----BEGIN X----- und -----END X-----, wie Zertifikate, private Schlüssel und CSRs sie verwenden. Die Bezeichnungen müssen an beiden Enden übereinstimmen; ein Block, bei dem BEGIN und END abweichen, wird als beschädigt gemeldet statt still dekodiert.
• OpenPGP ASCII-Armor — der Verwandte von PEM, mit optionalen Armor-Headern und einer =CRC24-Prüfsummenzeile. Die Prüfsumme wird verifiziert — sie ist die einzige Integritätsprüfung, die irgendeine Base64-Variante mitbringt, und ein Tool, das sie ungeprüft entfernt, hat den einzigen Beleg weggeworfen, den das Format bietet.
• Data-URI — data:image/png;base64,…, also das, was beim Kopieren eines eingebetteten Bildes aus CSS oder den Entwicklerwerkzeugen entsteht. Das Präfix wird entfernt, und sein angegebener Medientyp und Zeichensatz werden verwendet statt geraten.
• JWT — drei base64url-Segmente, getrennt durch Punkte. Wird an den Punkten geteilt, sodass Header und Payload jeweils als das JSON dekodieren, das sie sind — auch Tokens mit leerem Signatursegment, wie alg:none sie erzeugt und wie eine striktere Teilung sie ablehnen würde.

Diesen Teil lassen die meisten Base64-Decoder aus, und genau deshalb liefern so viele von ihnen einen Bildschirm voller Fragezeichen. Base64 sagt nichts über seinen Inhalt. Sind die Bytes aber erst einmal da, sagen sie es meist selbst: Fast jedes Binärformat beginnt mit einer Signatur, und die zu lesen ist billig.

Rund vierzig Signaturen werden geprüft: Bilder (PNG, JPEG, GIF, WebP, BMP, ICO, TIFF, AVIF, HEIC), Dokumente (PDF, RTF), Archive (ZIP, gzip, bzip2, xz, zstd, 7z, RAR), Audio und Video (MP3, FLAC, Ogg, WAV, MP4, WebM, AVI), Schriften (TTF, OTF, WOFF, WOFF2) und ausführbare Dateien. ZIP-basierte Formate werden einen Schritt weiter verfeinert, indem der Name des ersten Eintrags im Archiv gelesen wird — ein dekodiertes .docx wird also als .docx angeboten und nicht als .zip, und eine OpenDocument-Datei wird über den Medientyp in ihrem eigenen mimetype-Eintrag erkannt. Passt nichts, wird geprüft, ob die Bytes überhaupt Text sind — ein NUL-Byte ist das Signal, mit einer Ausnahme für UTF-16, das konstruktionsbedingt zur Hälfte aus NUL-Bytes besteht — und Text, der mit einer geschweiften Klammer beginnt, wird nur dann JSON genannt, wenn er sich tatsächlich parsen lässt.

Zwei Dinge folgen daraus, die du in der Oberfläche siehst. Die Download-Schaltfläche bietet die Datei unter der Endung an, die ihre eigenen Bytes rechtfertigen — ein dekodiertes PNG wird als .png gespeichert und öffnet sich mit einem Doppelklick. Und binäre Nutzdaten werden nie durch einen Textdecoder geschickt, um eine Seite voller U+FFFD-Ersatzzeichen zu erzeugen: Sie gehen direkt in die Hex-Ansicht, und das Panel sagt, was gefunden wurde.

Das ist der häufigste Grund dafür, dass eine Dekodierung „falsch aussieht“, und es ist kein Fehler im Decoder. Base64 kodiert Bytes. Es hat kein Feld für eine Kodierung, keinen Header und keine Konvention dafür. Jedes Tool, das dir Text zeigt, hat für dich eine Kodierung gewählt, und die meisten sagen nicht, welche.

• Eine Bytereihenfolge-Markierung ist eine Aussage — beginnen die dekodierten Bytes mit einer BOM, hat der Erzeuger die Kodierung genannt, und die wird verwendet. UTF-8, UTF-16 in beiden Byte-Reihenfolgen und UTF-32 in beiden werden erkannt.
• Ein Data-URI kann eine angeben — data:text/plain;charset=windows-1251;base64,… nennt seinen eigenen Zeichensatz, und der wird beachtet — steht aber unter der BOM, weil eine BOM in den Daten selbst steckt und der Parameter nur eine Behauptung darüber ist.
• Gültiges UTF-8 ist fast ein Beweis — UTF-8 hat genug Struktur, dass ein Dokument beliebiger Länge kaum zufällig gültig ist. Lassen sich die Bytes streng als UTF-8 dekodieren, sind sie das auch.
• Reines ASCII beweist nichts — ASCII ist gültiges UTF-8 und in jedem Einbyte-Satz gültig, die Frage hat also keine Antwort. Das Tool sagt „mehrdeutig“, statt eine sichere Erkennung zu behaupten, die die Daten nicht hergeben.
• Sonst ist es eine Vermutung, und sie wird so benannt — Nutzdaten, die kein gültiges UTF-8 sind, liegen in irgendeiner Einbyte-Kodierung vor, und die Bytes können nicht sagen, in welcher. Windows-1252 ist mit Abstand die häufigste und daher der Rückfall — als Vermutung gekennzeichnet, mit der vollen Liste einen Klick entfernt.

Einunddreißig Zeichensätze werden angeboten, und die Liste entsteht, indem der Browser gefragt wird, welche er tatsächlich unterstützt, statt die aufzuzählen, die er unterstützen sollte. UTF-32 ist die Ausnahme: Kein Browser implementiert es in seinem Textdecoder, es wird hier also direkt dekodiert — deshalb steht es überhaupt auf der Liste.

Base64 packt drei Bytes in vier Zeichen. Ist die Eingabelänge kein Vielfaches von drei, ist die Schlussgruppe kürzer — und einige Bits ihres letzten Zeichens gehören zu keinem Byte.

In einer zweizeichigen Schlussgruppe sind die letzten vier Bits übrig, in einer dreizeichigen die letzten zwei. Ein konformer Encoder schreibt dort Nullen. Nichts verpflichtet einen Decoder nachzusehen, und praktisch keiner tut es: QQ== und QR== dekodieren beide still zum einzelnen Byte 0x41 — in jedem Browser, in jedem Kommandozeilenwerkzeug und auf jeder Website, die wir geprüft haben. Einer dieser Strings kam von einem Encoder, der andere war beschädigt oder von Hand bearbeitet, und kein Tool unterscheidet sie.

Der strenge Modus prüft es. Bei eingeschaltetem strengem Modus ist es ein Fehler, sonst eine Warnung, sodass die Bytes trotzdem sichtbar bleiben — es geht nicht darum, die Daten abzulehnen, sondern darum, dass du weißt, dass der String nicht so entstanden ist, wie er vorgibt. Dasselbe gilt für Nutzdaten, die beide Alphabete mischen: - und _ kollidieren nie mit + und /, es dekodiert also eindeutig, aber eines von beiden ist fehl am Platz und jemand sollte das wahrscheinlich wissen.

Jede Ablehnung nennt Zeichenindex, Zeile und Spalte des Problems sowie das betroffene Zeichen. Keine der beiden Base64-Funktionen des Browsers meldet eine Position, und kein konkurrierendes Tool tut es — bei vier Megabyte Nutzdaten mit einem einzigen fehlerhaften Zeichen ist „ungültig“ keine Diagnose.

• Kein gültiges Base64 — ein Zeichen außerhalb des Alphabets. Im milden Modus wird das nur für wirklich fremde Zeichen gemeldet — Leerzeichen und Zeilenumbrüche werden vorher entfernt. Ein geschütztes Leerzeichen, wie es beim Kopieren aus einer gerenderten Webseite oft entsteht, gilt als fremd, und die Position sagt dir genau, wo es gelandet ist.
• Abgeschnitten — die Nutzdaten haben eine Schlussgruppe aus einem Zeichen, was keine Eingabe erzeugen kann. Das ist das einzige eindeutige „der String wurde abgeschnitten“-Signal, das Base64 hat.
• Daten nach der Auffüllung — nach den =-Zeichen stehen weitere Zeichen. Fast immer zwei aneinandergehängte Base64-Strings, aus denen jeder milde Decoder bereitwillig plausiblen Unsinn macht.
• Fehlende oder unerwartete Auffüllung — nur im strengen Modus. Die =-Zeichen fehlen, sind zu viele oder haben nicht die Länge, die die Länge der Nutzdaten verlangt.
• Leerraum nicht erlaubt — nur im strengen Modus und nur außerhalb der umbrochenen Formate. Zeilenumbrüche in MIME, PEM und PGP gehören zu diesen Formaten und bleiben zulässig.
• Falsches oder gemischtes Alphabet — nur im strengen Modus. Die Nutzdaten verwenden Zeichen aus dem nicht gewählten Alphabet oder aus beiden.

Base64 ist eine Kodierung, keine Verschlüsselung und keine Sicherheitsgrenze. Es dient dazu, Bytes durch Kanäle zu bewegen, die nur Text akzeptieren, und die Bytes am anderen Ende sind das, was jemand dort hineingelegt hat.

• Dekodierte Ausgabe ist nicht vertrauenswürdig — Nutzdaten können zu einem Skript, einer ausführbaren Datei oder Markup dekodieren, das anderswo ausgeführt werden soll. Dass etwas Base64 war, macht es nicht sicher, und dass es kodiert ankam, ist manchmal genau der Punkt.
• Füge keine Geheimnisse ein, die du auch anderswo nicht einfügen würdest — diese Seite läuft vollständig auf deinem Gerät und sendet nichts, was du mit den Netzwerkwerkzeugen deines Browsers prüfen kannst — aber die Gewohnheit, Zugangsdaten in Webformulare einzufügen, sollte man sich nicht angewöhnen, denn die meisten Seiten, die so aussehen wie diese, laden tatsächlich hoch.
• Die Payload eines JWT wird nicht verifiziert — ein Token zu teilen und seine Segmente zu dekodieren zeigt dir, was es behauptet. Die Signatur wird nicht geprüft, und jeder kann ein Token erzeugen, das irgendetwas behauptet. Lies es als Behauptung, nie als Tatsache.
• Eine Armor-Prüfsumme ist keine Signatur — die CRC-24 in einem PGP-Block erkennt zufällige Beschädigung. Sie ist keine kryptografische Prüfung und sagt nicht, wer den Block erzeugt hat.

Base64 kommt nicht nur über die Zwischenablage. Es wird in .txt- und .b64-Dateien gespeichert, in .pem-Zertifikate und .asc-Armor-Blöcke, und in .json-, .xml- und .eml-Dokumente eingebettet — all das kann auf die Seite gezogen werden.

Was kostenlos enthalten ist

Bis zu 25 MB Base64, eine Eingabe zur Zeit, und jede Fähigkeit des Tools: alle sieben Eingabeformate, alle einunddreißig Zeichensätze, der strenge Modus, die Hex- und ASCII-Ansicht, die Dateityperkennung, der typisierte Download und die Aufteilungsmodi. Die Grenze betrifft den Umfang, nie die Funktion — 25 MB Base64 sind etwa 18,75 MB dekodierte Daten, nach jedem normalen Maßstab eine große Nutzlast.

Was Pro hinzufügt

Bis zu zwanzig Eingaben gleichzeitig, alle als ein einziges Archiv herunterladbar, und statt der festen Größengrenze das, was dein Gerät tatsächlich verkraftet, statt einer bloß größeren festen Zahl. Die Kompression im Archiv wird pro Datei danach gewählt, was die Nutzdaten sind — ein Stapel dekodierter Bilder wird gespeichert statt sinnlos neu komprimiert, ein Stapel dekodierten JSONs wird komprimiert.

Mehrere Kodierungen sehen Base64 ähnlich genug, um damit verwechselt zu werden, und ein Decoder, der sie trotzdem annimmt, erzeugt überzeugenden Unsinn. Ist die Ausgabe Kauderwelsch und liegt es nicht am Zeichensatz, prüfe, ob die Eingabe eines der folgenden ist.

• Prozent-Kodierung — %20 und %E2%9C%93 sind URL-Kodierung, kein Base64. Nutze stattdessen den URL-Encoder und -Decoder.
• Hexadezimal — ein String nur aus 0–9 und a–f mit gerader Länge ist weit eher Hex als Base64 — und Hex ist auch gültiges Base64, genau deshalb erzeugt der Irrtum eine Dekodierung statt eines Fehlers.
• Base32 — Großbuchstaben A–Z und 2–7, aufgefüllt mit =. Es teilt das Auffüllzeichen und sonst nichts.
• Ein Hash — ein MD5-, SHA-1- oder SHA-256-Digest ist keine kodierten Daten und lässt sich zu nichts zurückverwandeln. Es ist ein Einwege-Fingerabdruck; nutze den Hash-Generator, um einen zu erzeugen.
• Bereits dekodierter Text — gewöhnliche Wörter bestehen aus Base64-Zeichen, ein in einen Decoder eingefügter Satz „dekodiert“ also zu Bytes. Ist das Ergebnis binär und war die Eingabe lesbar, war die Eingabe nicht kodiert.

Greife zum Decoder, wenn du bereits einen Base64-String hast und wissen willst, was darin steckt. Für die Gegenrichtung nutze den Encoder.

• Ein Base64-Feld in einer API-Antwort, einem Webhook-Body oder einer Logzeile prüfen.
• Header und Payload eines JWT lesen, um zu sehen, was ein Token behauptet.
• Ein Bild oder eine Schrift aus einem in CSS, HTML oder SVG eingebetteten Data-URI holen.
• Prüfen, was ein PEM-Zertifikat oder ein PGP-Armor-Block tatsächlich enthält.
• Text zurückgewinnen, der als Base64 in einer Datenbankspalte oder .env-Datei liegt.
• Mit dem strengen Modus bestätigen, dass ein Encoder konforme Ausgaben erzeugt hat.
• Eine Base64-Nutzlast in eine echte, mit der richtigen Endung versehene Datei zurückverwandeln.

Der Decoder nutzt den Base64-Pfad, den dein Browser bietet — die neuesten Browser haben einen eingebauten, ältere fallen auf einen Weg zurück, den es überall gibt und der bytegleiche Ausgaben liefert. Es gibt nichts zu konfigurieren und nichts zu installieren. Die Zeichensätze kommen vom Browser, die genaue Liste unterscheidet sich also minimal zwischen Engines; das Tool zeigt, was deiner tatsächlich unterstützt, nicht was er unterstützen sollte.

Die Dekodierung läuft abseits des Haupt-Threads auf deinem Gerät und nutzt den schnellsten Base64-Pfad, den dein Browser bietet. Auf einem Desktop-Rechner gemessen dekodiert eine 25-MB-Nutzlast in etwa 170 Millisekunden, einschließlich der Erkennung, worum es sich bei den Bytes handelt.

• Base64-Encoder
• Base64 Encoder/Decoder
• URL-Encoder/Decoder
• Hash-Generator
• UUID-Generator
• QR-Code-Leser
• JSON-Formatierer
• JSON-Validator
• JSON-Minifizierer
• XML zu JSON
• Groß-/Kleinschreibung ändern
• Text zuschneiden
• Farbkonverter
• Alle Konverter