Base64, Base64URL, URL-Prozentkodierung, HTML-Entitäten und Hex beim Tippen kodieren oder dekodieren, mit voller UTF-8-Unterstützung.
Nichts, was Sie eingeben, wird gespeichert - es wird in derselben Anfrage umgewandelt und zurückgegeben.
Ein Token im Log, ein Query-String in einer Weiterleitung, eine E-Mail voller & - kodierter Text begegnet einem im Büro ständig. Fügen Sie ihn hier ein, wählen Sie das Format und sehen Sie das kodierte oder dekodierte Ergebnis schon beim Tippen.
Ein JSON Web Token besteht aus drei Base64URL-Teilen, getrennt durch Punkte: Header, Payload und Signatur. Fügen Sie den mittleren Teil ein, wählen Sie Base64URL und dekodieren Sie - Sie sehen die JSON-Claims wie die Benutzer-ID und den Ablauf exp (ein Unix-Timestamp, den Sie mit dem Unix-Timestamp-Konverter lesen können). Dekodieren ist nicht Verifizieren: Jeder kann den Payload eines JWT lesen, und nur die Signaturprüfung auf dem Server beweist, dass er nicht verändert wurde.
Base64 ohne Padding, das manche Systeme weglassen, um Platz zu sparen, scheitert in strengen Decodern; dieses Tool ergänzt die fehlenden =-Zeichen und sagt Ihnen das. Für viele Server bedeutet ein + im Query-String ein Leerzeichen, daher kommt ein unkodiert in einen Link eingefügter Base64-Wert beschädigt an; kodieren Sie ihn als URL-Komponente oder nutzen Sie Base64URL. Doppelt kodierter Text zeigt sich als %2520 oder & und muss zweimal dekodiert werden.
Die Base64-Dekodierung ignoriert Leerzeichen und Zeilenumbrüche, ein über mehrere Zeilen umbrochener Wert wie in einer E-Mail wird also so dekodiert, wie er eingefügt wurde. Base64URL akzeptiert auch + und /, normales Base64 lehnt dagegen - und _ ab, ein JWT-Teil braucht also die Option Base64URL. Die Hex-Dekodierung überspringt Leerzeichen, Doppelpunkte, Kommas, Bindestriche und 0x-Präfixe, 48:65:6c:6c:6f und 0x48 0x65 funktionieren also beide. Die URL-Dekodierung macht aus + ein Leerzeichen, ein echtes Pluszeichen muss daher als %2B ankommen. Die HTML-Kodierung maskiert die fünf Zeichen & < > " und '; die HTML-Dekodierung kennt jede benannte HTML5-Entity wie und … sowie numerische wie ₹ für das Rupie-Zeichen.
Die URL-Kodierung dieses Tools kodiert einen einzelnen Wert, etwa einen Query-Parameter, und maskiert daher jedes reservierte Zeichen: https://example.com/a b?x=1&y=2 wird zu https%3A%2F%2Fexample.com%2Fa%20b%3Fx%3D1%26y%3D2. Kodieren Sie nur den Wert, den Sie in einen Link einsetzen, nie den ganzen Link. Text außerhalb von ASCII wird als seine UTF-8-Bytes kodiert: café ₹ wird zu caf%C3%A9%20%E2%82%B9, und Hex zeigt dieselben Bytes, é als c3 a9 und ₹ als e2 82 b9. Base64 von user:pass ist dXNlcjpwYXNz, der Wert in einem HTTP-Basic-Authorization-Header (RFC 7617); deshalb kann jeder, der diesen Header sieht, das Passwort lesen.
Die Bytes waren UTF-8, wurden aber irgendwo vor dem Kodieren als Latin-1 oder Windows-1252 gelesen. Die Dekodierung hier zeigt die Bytes, wie sie sind; beheben muss man das in dem System, das sie erzeugt hat.
Fügen Sie bis zu 200.000 Zeichen Text ein. Bei Binärdateien wie Bildern werden die dekodierten Bytes als Hex angezeigt statt als Download ausgegeben.
Nein. Base64 ändert nur die Schreibweise der Bytes, damit sie Systeme überstehen, die reinen Text erwarten. Jeder kann es dekodieren; verwenden Sie es nie, um ein Passwort oder Geheimnis zu verbergen.
Base64URL ersetzt "+" und "/" durch "-" und "_" und lässt das "="-Padding meist weg, sodass das Ergebnis in URLs und Dateinamen sicher ist. JSON Web Tokens verwenden es.
Nein. Er wird in derselben Anfrage umgewandelt und zurückgegeben und nie in eine Datenbank oder ein Log geschrieben.
Dieses Tool maskiert zusätzlich ! ' ( ) und *, die encodeURIComponent unverändert lässt, daher wird it's (50%) off! zu it%27s%20%2850%25%29%20off%21. Beide Formen dekodieren zum selben Text, und das Maskieren dieser Zeichen ist in einem Query-Wert immer unbedenklich. Ein Leerzeichen wird zu %20, nicht zu +; die Form mit + stammt aus der HTML-Formularkodierung, und der Decoder hier liest beide.
Unter Linux oder Mac ergibt echo -n 'Hello, World' | base64 das Ergebnis SGVsbG8sIFdvcmxk, und echo 'SGVsbG8sIFdvcmxk' | base64 --decode macht daraus wieder Text. Ohne -n hängt echo einen Zeilenumbruch an, der mitkodiert wird, und es entsteht SGVsbG8sIFdvcmxkCg==: der häufigste Grund, warum zwei Tools nicht übereinstimmen. In PowerShell kodiert [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello, World')), und [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8sIFdvcmxk')) dekodiert. Diese Seite kodiert genau die eingefügten Zeichen als UTF-8 und hängt keinen Zeilenumbruch an.
Fügen Sie nur den Teil nach dem Komma ein: In data:image/png;base64,iVBORw0KGgo... ist das iVBORw0KGgo..., denn das Präfix data:image/png;base64, ist kein Base64, und die ganze Zeichenkette wird abgelehnt. Wählen Sie Base64 und Decode. Bytes, die kein Text sind, erscheinen als Hex statt als Bild, und das reicht, um die Dateiart zu erkennen: Ein PNG beginnt mit 89 50 4e 47, ein JPEG mit ff d8 ff und eine ganze .docx-, .xlsx- oder andere ZIP-basierte Datei mit 50 4b 03 04. Um das Bild selbst zu sehen, fügen Sie die vollständige Data-URI in die Adresszeile des Browsers ein. Die Eingabe ist auf 200.000 Zeichen begrenzt, das sind etwa 150.000 Byte Datei.
Base64 schreibt je 3 Bytes als 4 Zeichen und füllt die letzte Gruppe mit = auf ein Vielfaches von 4 auf (RFC 4648), die Ausgabe ist also 4/3 der Eingabe-Bytes, aufgerundet. Hello, World sind 12 Bytes und werden zu den 16 Zeichen SGVsbG8sIFdvcmxk. Gezählt werden UTF-8-Bytes, nicht Buchstaben: café hat 4 Zeichen, aber 5 Bytes und ergibt Y2Fmw6k=, ₹100 hat 6 Bytes und ergibt 4oK5MTAw. E-Mail-Anhänge wachsen noch etwas mehr, weil MIME Base64 in Zeilen von höchstens 76 Zeichen umbricht (RFC 2045); diese Seite ignoriert diese Zeilenumbrüche beim Dekodieren. Base64URL ohne Auffüllung spart nur die =-Zeichen.