Base64-kodare/avkodare Online

Vad är detta verktyg?

Base64 är ett kodningssystem som omvandlar binär- eller textdata till en uppsättning av 64 säkra ASCII-tecken (A–Z, a–z, 0–9, + och /). Det används överallt i mjukvara: bädda in bilder i HTML/CSS, HTTP Basic-autentiseringsheaders, e-postbilagor (MIME), JSON Web Tokens och API-nyttolaster som måste överleva textbaserade kanaler.

Viktigt: Base64 är en kodning, inte kryptering. Vem som helst kan avkoda den. Syftet är att göra data säker att skicka genom system som bara förstår text — inte att hålla den hemlig.

Base64 specificeras formellt i RFC 4648, som också definierar den URL-säkra varianten som används i JWT:er och webb-API:er: den ersätter + med - och / med _ så att den kodade strängen kan skickas inuti en URL utan procentkodning.

Varför använda det?

• Avkoda API-tokens, JWT-segment och autentiseringsheaders för att se vad de innehåller.
• Koda text för data-URI:er, konfigurationsfiler eller HTTP-headers.
• UTF-8-säkert: emoji och icke-latinska tecken kodas och avkodas korrekt.
• 100 % privat — omvandlingen sker i din webbläsare, ingenting laddas upp.
• Gratis, ingen inloggning, inga storleksgränser.

Så använder du det

1. Skriv eller klistra in ditt innehåll i inmatningsfältet.
2. Klicka på "Koda" för att omvandla text till Base64, eller "Avkoda" för att omvandla Base64 tillbaka till text.
3. Om avkodningen misslyckas är indatan inte giltig Base64 — kontrollera om det saknas tecken eller finns extra mellanslag.
4. Klicka på "Kopiera" för att kopiera resultatet.

Exempel

Inmatning

Hello, CodeKitHub! 你好 👋

Resultat

SGVsbG8sIENvZGVLaXRIdWIhIOS9oOWlvSDwn5GL

Lägg märke till hur de kinesiska tecknen och emojin överlever tur och retur — det är den UTF-8-säkra delen.

Praktiska tips

• JWT-tokens är tre Base64-segment sammanfogade med punkter — avkoda de två första (header och payload) separat för att läsa dem; det tredje är en binär signatur och kommer att se ut som brus.
• Om avkodningen misslyckas på ett JWT-segment beror det på base64url-kodning: ersätt - med + och _ med / först (standardverktyg förväntar sig alfabetet +/).
• Mellanslag och radbrytningar i en Base64-sträng är oftast ofarliga rester från e-post eller loggar, men en saknad avslutande =-utfyllnad är det oftast inte — kontrollera längden innan du antar att datan är skadad.
• Base64 gör data ungefär 33 % större. Fint för små nyttolaster; för bilder över några KB är en riktig fil nästan alltid ett bättre val än en data-URI.

Verkliga användningsscenarier

De tre fall som får folk att hamna här dagligen: läsa vad som finns i en Authorization-header eller JWT, avkoda ett webhook-/API-nyttolastfält som kom Base64-inbäddat (ofta JSON — formatera det efter avkodning), samt manuellt skapa en data-URI eller Basic-Auth-sträng under felsökning.

För binär data (bilder, filer), kom ihåg att det du får när du avkodar som text är rappakalja — datan kan vara helt korrekt, den är bara inte text. Kodning/avkodning av binärdata hör hemma i kod; det här verktyget är optimerat för textfallen.

Hur man felsöker ett avkodningsfel

Fel vid Base64-avkodning kan nästan alltid spåras till en av tre orsaker, i fallande frekvensordning: indatan var faktiskt base64url (använder - och _ istället för de vanliga + och /, vanligt i JWT:er och URL-säkra kontexter) och behöver få dessa tecken bytta tillbaka innan standardavkodning accepterar den; strängen blev avkortad någonstans på vägen (en kopiering som missade de sista tecknen, eller en loggrad som klipptes av), vilket går att upptäcka eftersom en giltig Base64-strängs längd alltid är en multipel av 4 när utfyllnad räknats in; eller enstaka avvikande tecken (extra mellanslag, ett oavsiktligt radbyte, ett dubblerat tecken) infördes vid kopiering, vilket är varför det alltid är säkrare att klistra in direkt från originalkällan istället för att skriva om texten.

→ JSON-formaterare · URL-kodare/avkodare · JWT-avkodare

Vanliga frågor