Füge einen Base64-String oder eine Data URI ein und dekodiere ihn zurück in eine PNG-, JPG-, WebP- oder SVG-Datei mit Vorschau und Download – alles im Browser, nichts wird hochgeladen.
Ein data:-Präfix ist optional. Ohne Präfix wird das Format aus den dekodierten Bytes bestimmt, nicht aus einer Bezeichnung.
Der Download liefert die ursprüngliche Binärdatei, keinen Text
Ein Eingabefeld, drei Arten es zu füllen — und alle drei akzeptieren dieselbe Bandbreite an Strings.
Ein Base64-String erreicht dich in der Form, die das erzeugende Werkzeug gerade vorgegeben hat: als reine Nutzlast aus einer API-Antwort, als vollständige data:image/png;base64,…-URI aus einem Stylesheet, als zitierter Ausschnitt aus einer Logzeile oder als URL-sichere Variante aus einem Token. Dieser Decoder normalisiert all das, bevor er einen einzigen Byte ansieht. Die Form des Strings ist damit nie etwas, das du von Hand aufräumen musst.
Der Knopf liest die Zwischenablage direkt aus. Praktisch, wenn der String länger ist als du scrollen möchtest, und wenn die Quelle zwar kopiert, aber nicht auswählen lässt.
Strg+V (auf macOS Cmd+V) bei fokussierter Seite — du musst nicht erst ins Feld klicken. Einfügen ist die Geste, um die dieses Werkzeug herum gebaut ist, also funktioniert sie überall.
Das Bearbeiten läuft live: das Bild erscheint und aktualisiert sich mit dem String. Damit kannst du einen abgeschnittenen Text Zeichen für Zeichen bis zum letzten gültigen Zeichen kürzen und zusehen, wann wieder ein Bild daraus wird.
Was als gültiger String zählt. Zeilenumbrüche und Leerzeichen werden ignoriert, ein umbrochener String funktioniert also direkt. Das URL-sichere Alphabet (- und _) wird übersetzt, fehlendes =-Padding ergänzt. Umschließende Anführungszeichen, url(…)-Hüllen und jedes data:-Präfix werden entfernt. Nur Zeichen, die wirklich kein Base64 sind, bleiben übrig und werden als Fehler gemeldet.
Das Dekodieren ist ein einziger Funktionsaufruf. Zu wissen, was die Bytes sind, ist der Teil, der ein brauchbares Werkzeug von einem scheinbar brauchbaren trennt.
Ein reiner Base64-String trägt überhaupt keine Typinformation. Er ist nur eine Zahl zur Basis 64 — kein Byte darin sagt „PNG“ oder „JPEG“. Der einzige Hinweis ist das data:-Präfix, und das ist eine Bezeichnung, die irgendwer geschrieben hat, keine Tatsache über die Bytes. Bezeichnungen wandern bei umbenannten Dateien mit, werden beim Formatwechsel mitkopiert und von manchen Exportern fest verdrahtet, ohne je geprüft zu werden.
Deshalb liest dieses Werkzeug die Bytes. Es gleicht die ersten Bytes gegen die bekannten Signaturen aller unterstützten Formate ab und behandelt das Präfix als zu überprüfende Behauptung statt als Wahrheitsquelle. Widersprechen sich beide, erfährst du, wer gewonnen hat — denn eine falsch etikettierte Datei ist etwas, das man wissen will, bevor man sie unter der falschen Endung speichert.
| Prüfung | Was sie abfängt |
|---|---|
| Alphabet | Zeichen, die Base64 nicht enthalten kann — das Anführungszeichen oder die Zeilennummer, die beim Kopieren aus dem Quelltext mitgekommen sind. |
| Länge | Die Zeichenzahl wird vor dem Dekodieren gegen die Obergrenze geprüft. Eine zu große Einfügung wird also abgelehnt, statt allokiert zu werden. |
| Arithmetik | Base64 kodiert 3 Bytes zu 4 Zeichen, eine Länge von 4n + 1 kann es daher nicht geben. Dieser Rest heißt: der String ist abgeschnitten — und wird als Abschneiden gemeldet, nicht als unklares Dekodierproblem. |
| Signatur | Die dekodierten Bytes werden gegen die Formatssignaturen geprüft. Passt keine, ließ sich der String zwar dekodieren, ist aber kein Bild — und das wird gesagt, statt eine Datei mit irreführender Endung zu speichern. |
| Übereinstimmung | Ein data:-Präfix, das der Signatur widerspricht, wird als Warnung angezeigt; die Bytes gewinnen. |
„Online“ heißt: keine Installation, keine Anmeldung. Es heißt nicht, dass dein String über einen fremden Server läuft.
Viele Konverter schicken deinen String an ein Backend, dekodieren ihn dort und schicken das Bild zurück. Dieser hier erledigt alles im Speicher der Seite: Der String wird geparst, dekodiert und in einen Blob verwandelt, ohne dass auch nur eine Anfrage ihn transportiert. Das wiegt in dieser Richtung schwerer als in der anderen, denn Base64-Strings sind häufig genau das, was man nicht auf die Leitung legen wollte — ein eingebettetes Bild aus einem internen Dokument, eine Nutzlast aus einer internen API-Antwort, ein Screenshot, den dir jemand vertraulich geschickt hat.
Das ist keine Behauptung, die man glauben muss. Öffne die Entwicklerwerkzeuge, wechsle auf den Netzwerk-Tab und dekodiere etwas: Nichts, was den String oder das entstehende Bild trägt, verlässt die Seite.
Die Geschwindigkeit hängt nur an deiner CPU. Es gibt kein Tageslimit, weil kein Server mitzählt und nichts zu drosseln ist.
Entwicklerwerkzeuge, Netzwerk-Tab, String dekodieren. Du siehst nur die Anfragen, die diese Seite ohnehin geladen haben.
Das Ergebnis ist eine echte Binärdatei, keine textliche Darstellung davon. Genau hier steckt die Arbeit.
Dekodieren kehrt die Kodierung exakt um: je 4 Zeichen entstehen 3 Bytes, das Padding fällt weg, und übrig bleibt Byte für Byte die Datei, die kodiert wurde. Ein Bild durch dieses Werkzeug und wieder durch das andere zu schicken liefert die Originalbytes zurück — deshalb erzeugt der Download-Knopf etwas, das dein Betriebssystem erkennt, und keine Datei, die nur richtig aussieht.
Die Textform ist immer größer als die Datei, die sie trägt. Base64 verbraucht 4 Zeichen pro 3 Bytes, rund ein Viertel des Strings ist also Overhead — die Angabe „kleiner als der Text“ in der Ergebnisanzeige ist genau dieses Verhältnis, gemessen am tatsächlich eingefügten String und nicht geschätzt.
| Wert | Woher er kommt |
|---|---|
| Dekodierte Größe | Die echte Bytelänge des dekodierten Puffers — also die Größe der gespeicherten Datei, keine Schätzung aus der Stringlänge. |
| Kleiner als der Text | Das Verhältnis zwischen dekodierten Bytes und normalisierter Nutzlast, damit eingefügte Leerzeichen das Ergebnis nicht verzerren. |
| Pixel | Aus dem dekodierten Bild selbst gelesen. Erscheint als Strich, wenn das Format gültig ist, aber keine eigene Größe mitbringt — etwa ein SVG ohne width und height. |
| Erkannt | Das an den Bytes gemessene Format, mit der Behauptung des Präfixes daneben, sobald beide auseinandergehen. |
Jedes Format mit erkennbarer Signatur — bestimmt aus den dekodierten Bytes, nicht aus einer Bezeichnung.
| Format | Signatur und was sie für dich bedeutet |
|---|---|
| PNG | Geprüft über die vollständige Acht-Byte-Signatur. Verlustfrei, mit Transparenz, und das Format, das die meisten Screenshot-Werkzeuge ausgeben. |
| JPG / JPEG | Erkannt am FF D8 FF-Marker statt an einem bloßen FF D8, das als Beleg zu beliebig wäre. |
| GIF | Sowohl GIF87a als auch GIF89a. Die Vorschau zeigt nur das erste Bild, der Download enthält die ganze Animation. |
| WebP | Erkannt über den RIFF-Container-Kopf. |
| SVG | Auszeichnungssprache, keine Pixel — wird deshalb am Text erkannt und nicht an einer Bytesignatur. |
| BMP / ICO | Erkannt an den führenden Bytes. ICO ist hier das einzige Format, dessen Signatur mit einer Folge von Nullbytes beginnt. |
| AVIF | Aus dem ISO-Base-Media-Container gelesen, wobei die Marke geprüft statt angenommen wird — derselbe Container trägt auch HEIC, das Browser bis heute nicht darstellen können. |
SVG wird nie in diese Seite eingebettet. Ein dekodiertes SVG wird über ein <img>-Element angezeigt, in dem Skripte nicht ausgeführt werden. SVG- Markup direkt ins Dokument zu rendern ist der Weg, auf dem ein Decoder zum XSS-Vektor wird — und genau das machen viele Online-Konverter.
.png gespeichert, das sich nicht öffnen lässt.Füge den Base64-String oben in das Feld ein – mit oder ohne data:-URI-Präfix. Der Konverter prüft ihn, liest das echte Format aus den ersten Bytes der dekodierten Daten und zeigt das Bild an; mit Download speicherst du es als Datei.
Ja. Ein reiner Base64-String enthält überhaupt keine Typinformation, deshalb wird das Format aus den dekodierten Bytes selbst erkannt – mit derselben Magic-Byte-Prüfung, auf die sich die umgekehrte Richtung stützt. Ein vorhandenes Präfix gilt nur als Hinweis: widerspricht es den Bytes, gewinnen die Bytes, und die Seite sagt dir, dass das Präfix falsch war.
Drei Ursachen erklären fast alle Fälle: der String wurde beim Kopieren abgeschnitten, er enthält Zeichen außerhalb des Base64-Alphabets (etwa ein mitkopiertes Anführungszeichen oder eine Zeilennummer), oder er ist gar kein Base64. Das Werkzeug benennt den konkreten Fall, statt eine allgemeine Fehlermeldung auszugeben.
Ja. Leerzeichen und Zeilenumbrüche werden ignoriert, ein von E-Mail-Programmen oder Editoren umbrochener String lässt sich also weiterhin dekodieren. URL-sichere Varianten mit - und _ werden ebenso akzeptiert wie + und /, fehlendes =-Padding wird vor dem Dekodieren ergänzt.
PNG, JPG, GIF, WebP, BMP, ICO, SVG und AVIF, bis zu 10 MB dekodierte Daten. Das Format wird aus den Bytes bestimmt: ein als PNG bezeichneter String, der tatsächlich ein JPEG enthält, wird als JPEG dekodiert. SVG wird als Original-Markup zurückgegeben und als Bild angezeigt – nie als Markup in die Seite eingefügt.
Nein. Das Dekodieren läuft im Browserspeicher und der String wird nie übertragen. Du kannst das im Netzwerk-Panel deines Browsers überprüfen – die einzige Anfrage betrifft die Seite selbst.