Vad är Base64-kodning?
Base64-kodning är ett sätt att representera godtycklig binär data eller text med bara 64 skrivbara ASCII-tecken, så att den överlever system som bara hanterar text på ett säkert sätt. Var tredje byte indata blir exakt fyra Base64-tecken, vilket gör att resultatet blir cirka 33 % större än originalet, aldrig mindre.
Vad Base64-kodning faktiskt gör
Alfabetet består av 64 symboler: A till Z, a till z, siffrorna 0 till 9, samt tecknen + och /. Ett extra tecken, =, används enbart som utfyllnad i slutet av strängen när indatan inte går jämnt upp i grupper om tre byte. Det är hela mekaniken. Ingen nyckel, ingen hemlighet, bara en tabell som mappar sextiofyra bitmönster till sextiofyra tryckbara tecken.
Det är också värt att slå fast direkt: Base64 är varken kryptering eller komprimering. Det finns ingen hemlig nyckel någonstans i processen, vem som helst kan avkoda en Base64-sträng med ett verktyg som det nedan, och resultatet blir alltid större än indatan, inte mindre. Det här är den vanligaste missuppfattningen kring Base64, och den är farlig i praktiken: att “koda” ett lösenord eller en API-nyckel i Base64 skyddar ingenting. Det är att skriva om texten i ett annat teckenformat, inget annat. Om du behöver skydda data behöver du riktig kryptering med en nyckel som bara mottagaren har, inte en reversibel omkodning som alla kan vända tillbaka på tio sekunder.
Så fungerar det: att koda “Man” bit för bit
Den klassiska demonstrationen använder ordet “Man” eftersom det landar exakt på tre byte, det vill säga 24 bitar, som delar sig jämnt i fyra grupper om sex bitar. Varje bokstav motsvarar sitt ASCII-värde:
| Tecken | ASCII-värde | Binärt (8 bitar) |
|---|---|---|
| M | 77 | 01001101 |
| a | 97 | 01100001 |
| n | 110 | 01101110 |
Slå ihop de tre byten till en enda följd av 24 bitar: 010011010110000101101110. Base64 bryr sig inte om var bokstavsgränserna låg ursprungligen, den delar bara upp den långa bitsträngen i nya grupper om sex bitar istället för åtta:
| Grupp | Bitar | Decimalvärde | Base64-tecken |
|---|---|---|---|
| 1 | 010011 | 19 | T |
| 2 | 010110 | 22 | W |
| 3 | 000101 | 5 | F |
| 4 | 101110 | 46 | u |
Varje sexbitarsgrupp kan bara anta ett värde mellan 0 och 63, exakt de 64 positionerna i Base64-alfabetet. Slår man ihop tecknen från tabellen får man “TWFu”, vilket är precis vad “Man” blir kodat till. Det är inte magi, det är en baskonvertering: samma data skriven om från åttabitarsbyte till sexbitarsgrupper, med en ny symbol för varje ny grupp.
Utfyllnad: varför vissa Base64-strängar slutar på =
24 bitar delar sig perfekt i fyra sexbitarsgrupper, men verklig indata går sällan jämnt upp i multiplar av tre byte. När den inte gör det fyller Base64 ut den sista gruppen med nollor och lägger till ett eller två likhetstecken i slutet av strängen, som en markör för hur mycket av den sista gruppen som faktiskt är riktig data:
| Indata | Byte | Base64-utdata | Förklaring |
|---|---|---|---|
| ”M” | 1 byte | ”TQ==“ | En byte räcker inte till en full grupp om tre, så resultatet blir 2 tecken riktig data plus 2 utfyllnadstecken |
| ”Ma” | 2 byte | ”TWE=“ | Två byte ger 3 tecken riktig data plus 1 utfyllnadstecken |
| ”Man” | 3 byte | ”TWFu” | Tre byte fyller exakt fyra tecken, ingen utfyllnad behövs |
Likhetstecknen berättar alltså ingenting hemligt, de är bara bokföring: avkodaren vet exakt hur många av de sista bitarna som ska ignoreras. En sträng som slutar på == saknade två byte för en full grupp, en som slutar på ett enda = saknade en byte, och en sträng utan utfyllnad landade exakt jämnt.
Var du faktiskt stöter på Base64
Base64 dyker upp överallt där text är det enda säkra transportmediet men innehållet i grunden är binärt eller kan innehålla tecken som skulle krocka med protokollet. Några konkreta exempel, körda genom exakt samma algoritm som ovan:
“Hello, World!” blir “SGVsbG8sIFdvcmxkIQ==”. Det är precis vad HTTP Basic Authentication skickar: en Authorization: Basic <base64(user:pass)>-header bygger på samma kodning. Strängen “user:pass1234” blir till exempel “dXNlcjpwYXNzMTIzNA==”, vilket är exakt det värdet som hamnar i headern när en klient loggar in med grundläggande autentisering.
Ett annat vanligt fall är att bädda in ett litet strukturerat dataobjekt i en URL-parameter eller i en JWT-token. JSON-nyttolasten {"id":42,"active":true} blir “eyJpZCI6NDIsImFjdGl2ZSI6dHJ1ZX0=”. Just JWT-tokens (JSON Web Tokens) är tre Base64url-segment separerade med punkter: header.payload.signature. Det här verktyget är inte specialiserat på att tolka JWT-strukturen, men payload-segmentet är fullt läsbart med en helt vanlig Base64/Base64url-avkodare, precis den typ som avkodaren nedan är.
Data-URL:er i CSS och HTML är ett tredje exempel, där en bild eller ett teckensnitt kodas direkt in i stilmallen eller HTML-dokumentet istället för att laddas från en separat fil. E-postbilagor i MIME-format använder samma teknik för att skicka binära filer genom ett protokoll som ursprungligen bara var byggt för text.
Två exempel visar också en viktig detalj: Base64-kodning arbetar på byte, inte på synliga tecken. Ordet “café” ser ut som fyra bokstäver, men é tar upp 2 byte i UTF-8, så resultatet blir “Y2Fmw6k=”, åtta Base64-tecken snarare än de sex man kanske räknar med om man tänker i bokstäver istället för byte. En enda emoji, ”🚀”, är 4 byte i UTF-8 och kodas till “8J+agA==”. Astrala tecken som emojis behandlas inte annorlunda än något annat, de kodas byte för byte precis som alla andra tecken.
Koda eller avkoda din egen text
Skriv in valfri text i kodaren nedan och se resultatet uppdateras direkt, byte för byte, med samma logik som i “Man”-exemplet ovan.
Har du redan en Base64-sträng, till exempel ett payload-segment från en JWT eller en rad ur en data-URL, och vill se vad den faktiskt innehåller? Klistra in den i avkodaren:
Vanliga misstag och specialfall
Att behandla Base64 som kryptering eller ett säkerhetsskydd. Det tål att upprepas konkret eftersom det är ett så vanligt misstag i praktiken: att lägga ett API-lösenord eller en session-token i Base64 och kalla det “skyddat” är ett säkerhetsmisstag, inte bara en teknisk detalj. Vem som helst med fem sekunder och ett avkodningsverktyg läser klartexten.
Standard-Base64 är inte URL-säkert. Tecknen + och / ingår i det vanliga Base64-alfabetet, men båda har särskild betydelse i en URL eller frågesträng (+ tolkas ofta som mellanslag, / kan blandas ihop med sökvägsavgränsare), och ett = i fel läge kan skapa tvetydighet i en filnamn eller parameter. Därför finns en separat variant, Base64URL, som ersätter + med - och / med _, och ofta hoppar över utfyllnaden helt. Det här verktyget växlar inte mellan varianterna åt dig, men det förklarar varför vissa Base64-liknande strängar du ser i URL:er och JWT-tokens saknar +, / och = jämfört med strängarna i exemplen ovan.
Mellanslag, radbrytningar eller saknad utfyllnad. En strikt avkodare, till skillnad från en förlåtande sådan, kan vägra tolka en sträng som har fått ett mellanslag eller en radbrytning smugit in sig (vanligt när Base64 klistras in från e-post eller en textfil med radbrytningar på 76 tecken), eller som saknar sina =-tecken i slutet. Kontrollera alltid att strängen är hel och sammanhängande innan du felsöker något annat.
Att glömma att flerbytetecken kodas som byte, inte som synliga tecken. Som café- och raket-exemplen ovan visar kan en kort sträng med accenttecken, kinesiska tecken eller emojis bli betydligt fler Base64-tecken än vad en snabb koll på antalet bokstäver antyder.
Dubbelkodning av misstag. Att köra en redan Base64-kodad sträng genom kodaren en gång till producerar en ny, giltig Base64-sträng, men den avkodas bara tillbaka till den första kodade versionen, inte till originaltexten. Om resultatet efter avkodning fortfarande ser ut som strimlad text med bokstäver, siffror och kanske ett = på slutet, testa att avkoda en gång till.
Vanliga frågor
Är Base64 samma sak som kryptering? Nej. Base64 är en reversibel kodning utan någon hemlig nyckel. Vem som helst kan avkoda den med ett gratisverktyg som det ovan. Ska data faktiskt skyddas krävs riktig kryptering, inte Base64.
Varför blir Base64-utdatan alltid större än originalet? Eftersom varje grupp om 3 byte (24 bitar) skrivs om till 4 tecken där varje tecken bara bär 6 bitar istället för 8. Fyra tecken gånger sex bitar ger samma 24 bitar tillbaka, men i fyra tecken istället för tre byte, vilket ger en ökning på ungefär 33 %.
Varför slutar vissa Base64-strängar på ett eller två likhetstecken? Likhetstecknen är utfyllnad. De visas när indatan inte går jämnt upp i grupper om tre byte: en sista grupp på 1 byte ger två utfyllnadstecken, en sista grupp på 2 byte ger ett, och en sista grupp på exakt 3 byte kräver ingen alls.
Kan jag avkoda en JWT-token med det här verktyget? Du kan avkoda de enskilda segmenten. En JWT består av tre Base64url-segment separerade med punkter (header.payload.signature). Klistra in header- eller payload-segmentet i avkodaren ovan så får du tillbaka den underliggande JSON-texten, eftersom Base64url i grunden är samma kodning som vanlig Base64.
Varför ser vissa Base64-strängar i URL:er annorlunda ut, utan +, / eller =? De använder troligen Base64URL-varianten, som byter ut + mot - och / mot _ för att undvika konflikter med hur URL:er och frågesträngar tolkas, och ofta hoppar över utfyllnadstecknen helt. Innehållet representerar samma sorts data, bara med ett alfabet anpassat för att vara säkert i en webbadress.