Base64-kodare och avkodare

Introduktion

Base64-kodaren och avkodaren är ett gratis onlineverktyg för att konvertera text till Base64 och avkoda Base64 tillbaka till text. Båda operationerna sker i realtid medan du skriver, utan att sidan laddas om eller att du behöver trycka på en skicka-knapp. Verktyget körs helt i din webbläsare — inget skickas till en server.

Två oberoende sektioner finns på samma sida: en för kodning, en för avkodning. Var och en har sitt eget textfält, uppladdningszon och åtgärdsknappar, så att du kan arbeta i båda riktningarna utan att växla läge.

Vad är Base64?

Base64 är ett sätt att representera binära data med endast utskrivbara ASCII-tecken. Det är inte ett krypterings- eller komprimeringsschema — dess syfte är att göra binära data säkra att transportera över system som är utformade för text.

Hur kodningen fungerar

Base64-alfabetet använder 64 tecken:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

Kodningsprocessen delar upp indata i grupper om 3 byte (24 bitar) och delar sedan varje grupp i fyra 6-bitarsvärden. Varje 6-bitarsvärde (0–63) mappas till ett tecken i alfabetet.

Indata:      F   o   o
Binärt:      01000110 01101111 01101111
6-bit:       010001 100110 111101 101111
Decimalt:    17     38     61     47
Base64:      R     b    9     v

"Foo" kodas som Rm9v.

Varför 64?

64 valdes eftersom det är den största tvåpotensen som endast använder tecken som finns i nästan alla teckenuppsättningar (bokstäver, siffror och två skiljetecken). Detta gör Base64 pålitligt över e-postsystem, JSON-nyttolaster, webbadresser och andra textbaserade kanaler som kan förvränga eller avvisa icke-ASCII-byte.

Varje Base64-tecken bär 6 bitar information, jämfört med 8 bitar per byte. Detta 6:8-förhållande förklarar varför den kodade utdatan är ungefär 33 % större än den ursprungliga indatan — ett ämne som behandlas mer i detalj senare.

När indata inte är en multipel av 3 byte

Om den sista gruppen har färre än 3 byte läggs utfyllnad till. Kodaren lägger till =-tecken för att göra utdatalängden till en multipel av 4:

• 1 byte kvar → 2 Base64-tecken + ==
• 2 byte kvar → 3 Base64-tecken + =
• 3 byte kompletta → 4 Base64-tecken, ingen utfyllnad

Till exempel kodas "Fo" (2 byte) som Rm8=.

En not om vad Base64 inte är

Base64 förväxlas ofta med kryptering eftersom utdatan ser ut som slumpmässiga tecken. En snabb avkodning avslöjar den ursprungliga texten utan någon nyckel. Om du behöver skydda data, använd ett lämpligt krypteringsalgoritm (AES, ChaCha20, etc.) och koda sedan de krypterade byten med Base64 för transport. Base64 ensamt ger ingen konfidentialitet.

Vanliga användningsområden för Base64

Base64 förekommer på många vardagliga platser på webben, ofta utan att användare märker det.

Data-URI:er

Moderna webbläsare låter dig bädda in bilder, typsnitt och andra media direkt i HTML eller CSS med data:-URI:er:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...">

De Base64-kodade bilddata lever i HTML-filen själv — ingen separat HTTP-förfrågan behövs. Detta är vanligt för små ikoner, sprites och webbtypsnitt, där den extra HTTP-turen skulle kosta mer än inline-bytesen.

Base64 Data-URI:er är dock inte alltid det bästa valet för större tillgångar. 33 % storleksöverhead innebär att en 100 KB-ikon blir 133 KB inline-text, och webbläsaren kan inte cachelagra den separat från HTML-sidan. De flesta webbplatser använder Data-URI:er endast för tillgångar under några kilobyte.

JWT- och API-token

JSON Web Tokens använder Base64url (den URL-säkra varianten) för att koda rubrik-, nyttolast- och signatursegmenten i en token. Om du någonsin har inspekterat en JWT som denna:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

varje punktseparerat segment är Base64url-kodad JSON. Du kan klistra in vilket segment som helst i avkodningsdelen av detta verktyg för att inspektera dess innehåll.

E-postbilagor (MIME)

E-post var ursprungligen utformat för 7-bitars ASCII. För att skicka binära bilagor (bilder, PDF-filer, kalkylblad) kodar MIME-standarden dem som Base64. Din e-postklient avkodar dem automatiskt när du öppnar meddelandet.

En detalj som ibland orsakar förvirring: MIME Base64 bryter konventionellt rader vid 76 tecken. Om du extraherar Base64-data från en e-postkälla kan de innehålla inbäddade radbrytningar. Avkodaren i detta verktyg hanterar radbrytningar automatiskt — du kan klistra in flerradigt MIME Base64 utan att först ta bort radbrytningarna.

PEM-certifikat och nycklar

SSL/TLS-certifikat och privata nycklar distribueras i PEM-format, som omsluter Base64-kodad DER-data mellan rubrik- och fotradsrader:

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----

PEM är i huvudsak Base64 med en etiketterad omslag. Du kan avkoda Base64-kroppen i en PEM-fil för att inspektera dess råa DER-innehåll, även om resultatet blir binärt, inte läsbar text.

HTTP-grundläggande autentisering

HTTP Basic auth-huvudet kodar användarnamn:lösenord som Base64:

Authorization: Basic YWRtaW46c2VjcmV0

Strängen YWRtaW46c2VjcmV0 är Base64-kodningen av admin:secret. Base64 är här en serialiseringsmekanism, inte säkerhet — inloggningsuppgifterna är trivialt avkodningsbara för alla som ser huvudet.

Vad är en .b64-fil?

En .b64-fil är en vanlig textfil vars hela innehåll är en Base64-sträng. Ändelsen .b64 är en namngivningskonvention som signalerar "denna fil innehåller Base64-data" — i motsats till godtycklig text, källkod eller ett binärt format.

Du kan stöta på .b64-filer när:

• Du exporterar kodad utdata från verktyg som detta
• Du lagrar kryptografiska nycklar eller certifikat i ett portabelt textformat
• Du utbyter Base64-data mellan system som använder filbaserade arbetsflöden

Eftersom .b64-filer är vanlig text kan du öppna dem i vilken textredigerare som helst, inspektera innehållet eller kopiera strängen till en avkodare. Detta verktyg accepterar .b64-filer i både Kodnings- och Avkodningsdelen via dra-och-släpp eller filväljaren.

Hur det fungerar

Verktyget använder webbläsarens inbyggda Base64-funktioner med ett extra lager för UTF-8-säkerhet.

Kärnkonvertering

JavaScript tillhandahåller två inbyggda funktioner för Base64:

• btoa(indata) — konverterar en sträng till Base64 (binärt till ASCII)
• atob(indata) — konverterar Base64 tillbaka till en sträng (ASCII till binärt)

Dessa funktioner fungerar endast med Latin-1 (ISO-8859-1)-tecken. Om du skickar en sträng som innehåller kinesiska, japanska, emoji eller andra tecken utanför Latin-1-intervallet, kastar btoa() en DOMException.

UTF-8-säker kodning

För att korrekt hantera all Unicode-text omsluter verktyget de inbyggda funktionerna:

function encode(text, urlSafe, noPad) {
  let utf8 = encodeURIComponent(text);
  let base64 = btoa(utf8);
  if (urlSafe) base64 = base64.replace(/\+/g, '-').replace(/\//g, '_');
  if (noPad) base64 = base64.replace(/=+$/, '');
  return base64;
}

function decode(base64) {
  let restored = base64.replace(/-/g, '+').replace(/_/g, '/');
  while (restored.length % 4 !== 0) restored += '=';
  let utf8 = atob(restored);
  return decodeURIComponent(utf8);
}

encodeURIComponent konverterar texten till UTF-8-procentkodad form, som endast innehåller ASCII-tecken som btoa kan bearbeta. Avkodningsvägen vänder detta i omvänd ordning.

För att se varför detta är viktigt, försök att koda emojin "😊" direkt med btoa — den kastar ett fel. Med UTF-8-omslaget blir den J UmbKSA4bQ, som avkodas korrekt tillbaka till 😊.

URL-säker indatahantering

Avkodningsfunktionen utför alltid två transformationer innan den skickar strängen till atob:

1. Ersätt - med + och _ med / (ångra URL-säker kodning)
2. Lägg till =-utfyllnad om stränglängden inte är en multipel av 4

Detta innebär att du aldrig behöver ändra en inställning på avkodningssidan. Oavsett om din indata är standard Base64, URL-säkert Base64, med eller utan utfyllnad, hanterar avkodaren det automatiskt.

Händelseflöde

När du skriver eller klistrar in i ett textfält utlöses en input-händelseavlyssnare. Schemaläggaren buffrar snabba tangenttryckningar (avstudsade till cirka 16 ms för att passa en bildruta) och kör sedan kodnings- eller avkodningsfunktionen. Resultatet visas i utdatatextfältet vid nästa skärmuppdatering.

Standard Base64 vs URL-säkert Base64

De två kryssrutorna i Kodningsdelen motsvarar två väldefinierade varianter av Base64.

Standard Base64 (RFC 4648 §4)

Använder hela alfabetet: A–Z, a–z, 0–9, +, /. Detta är den ursprungliga formen och fungerar överallt, förutom där + och / har en speciell betydelse.

URL-säkert Base64 (RFC 4648 §5)

Ersätter de två tecknen som orsakar problem i webbadresser:

Standard Base64 Pz4/Pj8+QA== blir Pz4_Pj8- QA_ i URL-säker form (notera: utfyllnaden = utelämnas också i exemplet, även om URL-säkert kan använda utfyllnad).

När ska varje variant användas

Avkodningssidan i detta verktyg upptäcker automatiskt vilken variant som använts, så du kan klistra in vilket format som helst utan att ändra inställningar.

Ett vanligt missförstånd

Vissa utvecklare tror att URL-säkert Base64 är en annan algoritm. Det är det inte — endast två tecken i alfabetet ändras. Vilken standard Base64-avkodare som helst kan anpassas genom att mappa - → + och _ → / före bearbetning, vilket är exakt vad detta verktyg gör på avkodningssidan.

Utfyllnad i Base64

Tecknet = i slutet av en Base64-sträng är utfyllnad — det är inte en del av de kodade data.

Varför utfyllnad finns

Base64 bearbetar indata i grupper om 3 byte. Om den sista gruppen har färre än 3 byte lägger kodaren till = som utfyllnad för att göra den totala längden till en multipel av 4. Detta krävs av vissa avkodare och gör det möjligt att sammanfoga flera Base64-strängar utan tvetydighet.

Vad "utan utfyllnad" betyder

När du aktiverar "Utan utfyllnad" tar kodaren bort de avslutande =-tecknen från utdatan. Till exempel:

• Indata: Fo → Rm8= (med utfyllnad) → Rm8 (utan utfyllnad)
• Indata: Foo → Rm9v (ingen utfyllnad i något fall — exakt multipel av 3)

Många moderna system accepterar Base64 utan utfyllnad, och avkodaren i detta verktyg hanterar det alltid. Aktivera detta alternativ när systemet du skickar utdatan till inte kräver eller vill ha utfyllnad.

Interoperabilitetsmatris

Avkodningsdelen i detta verktyg accepterar alla fyra kombinationer automatiskt:

Det finns ingen inställning att justera. Avkodaren normaliserar indata före bearbetning.

När utfyllnad krävs

Vissa system kräver strikt utfyllnad, särskilt:

• Data-URI:er: data:image/png;base64,... — webbläsarens parser förväntar sig korrekt utfylld Base64.
• Äldre Base64-bibliotek: Vissa implementationer avvisar helt indata utan utfyllnad.

Om du är osäker på om målsystemet kräver utfyllnad, låt det vara aktiverat (standard). Att ta bort utfyllnad är endast säkert när du kontrollerar både kodaren och avkodaren.

Base64 vs Andra Kodningsscheman

Base64 är ett av flera binär-till-text-kodningsscheman, var och en med olika avvägningar i densitet, alfabetstorlek och användningsfall.

Varför Base64 är mest populärt

Base64 träffar sweet spot för de flesta praktiska tillämpningar. Jämfört med Hex — som fördubblar indatastorleken — är Base64s 33 % överhead betydligt mer effektiv. Jämfört med Base85 är Base64 enklare att implementera (varje språk har en inbyggd avkodare), och dess alfabet undviker citeringsproblem som Base85-tecken som " och \ kan orsaka i vissa sammanhang.

När ska man använda något annat

• Hex: När mänsklig läsbarhet och felsökning är viktigare än storlek. En Hex-sträng som 4f6f är omedelbart igenkännbar som kodad data; b293 är mindre uppenbar som Base64.
• Base32: När skiftlägesokänslighet krävs (t.ex. för att säga högt i telefon, tryckt på produkter). Base32 använder endast versaler och siffror.
• Base85: När varje byte överhead räknas i en begränsad kanal och du kontrollerar båda ändarna av pipeline.

För allmän webkodning förblir Base64 rätt standardval. Detta verktyg följer den konventionen.

Prestanda och storleksöverväganden

Base64 är enkelt och universellt, men det har verkliga kostnader som spelar roll när du arbetar med större data.

33 % överhead

Varje 3 byte indata blir 4 byte utdata, ett förhållande på 4:3. I praktiken, inklusive utfyllnad och radbrytningar, är överheaden cirka 37 % för små indata och stabiliseras på 33 % för tillräckligt stora indata.

Base64 och komprimering

Gzip (eller Brotli)-komprimering av Base64-text är i allmänhet ineffektiv. Base64-utdata har en enhetlig teckenfördelning — vart och ett av de 64 tecknen förekommer med ungefär samma frekvens — vilket eliminerar de mönster som komprimeringsalgoritmer utnyttjar. En komprimerad Base64-sträng är ofta endast 5–10 % mindre än den okomprimerade formen, jämfört med 60–80 % reduktion som är möjlig med original binära data.

Detta innebär:

• Gör inte Base64-kodning före komprimering. Komprimera först, koda sedan om det behövs.
• Förlita dig inte på transportkomprimering (t.ex. HTTP gzip) för att kompensera Base64-överheaden. Det kommer det inte att göra.

När ska man inte använda Base64

Base64 är meningsfullt när du behöver passa in binära data i en text-only-kanal. Om kanalen stöder binär överföring inbyggt, hoppa över Base64:

• Filuppladdningar: Använd multipart/form-data med rå binär data, inte Base64 i JSON. Filen anländer 33 % större till servern och tar längre tid att ladda upp.
• Databaslagring: Lagra binära data som BYTEA (PostgreSQL), BLOB (MySQL/SQLite) eller varbinary (MSSQL) istället för Base64-text.
• API-anrop mellan tjänster: Använd gRPC, Thrift eller MessagePack med binära fält istället för Base64-kodade JSON-strängar.

För textnyttolaster (JWT-nyttolaster, HTML-innehåll, e-postmeddelanden) är överheaden försumbar och bekvämligheten med Base64 värd avvägningen.

Cachelagringsimplikationer

När du bäddar in en Base64 Data-URI i HTML eller CSS blir det kodade innehållet en del av sidresursen. Webbläsaren kan inte cachelagra den Data-URI:n oberoende — varje ändring av sidan ogiltigförklarar den. En separat bildfil som begärs via <img src="icon.png"> kan cachelagras mellan sidor med en framtida Cache-Control-rubrik. För tillgångar större än några kilobyte är separata filer nästan alltid mer prestandaeffektiva.

Vanliga fallgropar och missuppfattningar

Base64 är enkelt, men flera återkommande missförstånd orsakar verkliga fel.

Base64 Är Inte Kryptering

Detta är den vanligaste missuppfattningen. Eftersom Base64-utdata ser ut som slumpmässiga tecken antar många utvecklare att den ger någon nivå av skydd. Det gör den inte. Avkodning kräver ingen nyckel eller hemlighet. Behandla varje Base64-sträng som offentligt läsbar text.

Om du ser en tjänst lagra lösenord eller API-nycklar som Base64, behandla det som ett säkerhetsproblem — data lagras i klartext.

Skiftlägeskänslighet

Base64-alfabetet skiljer på versaler och gemener:

• Versaler: A–Z (värden 0–25)
• Gemener: a–z (värden 26–51)

Ett stavfel som R vs r ändrar det avkodade värdet helt. Om din avkodade utdata ser fel ut, kontrollera efter skiftlägesfel i indata.

MIME-radbrytningar

MIME-kodade e-postbilagor bryter Base64-kroppen var 76:e tecken:

SGVsbG8sIHdvcmxkISBUaGlzIGlzIGEgdGVzdCBvZi BiYXNlNjQgZW5jb2Rpbmcu
VGhpcyBpcyB0aGUgc2Vjb25kIGxpbmUu

Alla Base64-avkodare hanterar inte dessa inbäddade radbrytningar. Detta verktyg gör det — klistra in flerradigt MIME Base64 direkt utan förbearbetning. En avkodare som inte hanterar radbrytningar producerar ett förvrängt resultat eller ett fel.

Dolda blanksteg

Att kopiera text från e-post, PDF-filer eller webbsidor kan introducera osynliga blankstegstecken (mellanslag, tabbar, nollbreddstecken, fasta mellanslag). Dessa är inte giltig Base64. Om en till synes giltig Base64-sträng inte avkodas, klistra in den i en vanlig textredigerare först för att kontrollera dolda tecken, eller kopiera om från källan.

Sammanfogning av strängar med utfyllnad

Två Base64-strängar med utfyllnad som sammanfogas direkt avkodas inte nödvändigtvis korrekt. Utfyllnaden = tillhör den sista gruppen av varje sträng, och sammanfogning kan skapa tvetydiga gränser. Detta är avsiktligt — utfyllnad förhindrar tvetydighet för enskilda strängar. För data i flera delar, hantera varje del separat.

Användning

Att använda Base64-kodaren och avkodaren kräver ingen installation, registrering eller konto.

Koda text till Base64

1. I avsnittet Base64-koda, skriv eller klistra in din text i indata-textfältet.
2. Utdatfältet uppdateras automatiskt med det kodade resultatet.
3. Aktivera eventuellt URL-säkert för den webb säkra varianten, eller Utan utfyllnad för att ta bort avslutande =-tecken.
4. Klicka på Kopiera för att kopiera den kodade texten till urklipp, eller Ladda ner Base64 för att spara den som en .b64-fil.

Avkoda Base64 till text

1. I avsnittet Base64-avkoda, klistra in en Base64-sträng i indatafältet.
2. Den avkodade texten visas omedelbart i utdatafältet.
3. Om indata inte är giltig Base64 visas ett felmeddelande istället.
4. Klicka på Kopiera eller Ladda ner för att spara det avkodade resultatet.

Använda filuppladdning

• Kodningsdelen: släpp en .txt-fil på uppladdningszonen för att ladda dess innehåll för kodning.
• Avkodningsdelen: släpp en .b64- eller .txt-fil för att ladda Base64-innehåll för avkodning.

Filens innehåll läses, placeras i indata-textfältet och bearbetas omedelbart.

Handledning

Scenario: Du bygger en webbapplikation som kommunicerar med ett API. API:et förväntar sig att förfrågningsnyttolasten innehåller ett kort textfält kodat som URL-säkert Base64 utan utfyllnad. Du måste koda din text, verifiera utdatan och bekräfta att API:et accepterar den. Senare får du ett svar från samma API med ett Base64-kodat fält som du måste avkoda.

Denna handledning leder dig genom hela rundan.

Del 1: Koda

1. Öppna Base64-kodaren och avkodaren i din webbläsare. Du ser två sektioner sida vid sida — Koda till vänster, Avkoda till höger.

2. Skriv följande text i Kodnings-indatafältet:

   Hej, API-server. Detta är min nyttolast.
   

   Utdatfältet visar omedelbart standard Base64-kodningen. Resultatet börjar med SGVqLCBBUEk. Så långt bra.

3. API-specifikationen kräver URL-säkert Base64 utan utfyllnad. Aktivera båda kryssrutorna URL-säkert och Utan utfyllnad. Observera hur utdatan ändras:

   • +-tecken (om några) blir -
   • /-tecken blir _
   • Avslutande =-tecken försvinner

4. Klicka på Kopiera för att kopiera det kodade resultatet till ditt urklipp. Klistra in det i din API-förfrågningsnyttolast.

Del 2: Avkoda

5. API:et svarar med en JSON-nyttolast som innehåller ett Base64-kodat fält:

   {
     "status": "ok",
     "message": "eyJzdWIiOiAiMTAwMSIsICJuYW1lIjogIkFQSSBHYXRld2F5In0="
   }
   

6. Kopiera värdet av message och klistra in det i Avkoda-indatafältet.

   Utdatfältet visar omedelbart den avkodade texten:

   { "sub": "1001", "name": "API Gateway" }
   

7. Den JWT-liknande JSON-nyttolasten är nu läsbar. Om API:et hade använt URL-säkert Base64 (inga + eller / i strängen, eller med - och _), skulle avkodaren ha hanterat det automatiskt.

Del 3: Filbaserat arbetsflöde

8. Anta att du måste skicka den kodade nyttolasten till en kollega som föredrar filer. Klicka på Ladda ner Base64 i Kodningsdelen. Din webbläsares Spara som-dialogruta öppnas och föreslår download.b64 som filnamn. Spara filen.

9. Din kollega får filen och öppnar samma verktyg. Han drar download.b64 till uppladdningszonen i Avkoda-delen. Filinnehållet visas i indatafältet och den avkodade texten visas omedelbart.

Denna runda — koda med alternativ → kopiera eller ladda ner → avkoda med automatisk detektering — täcker det vanligaste verkliga arbetsflödet. Verktyget hanterar all normalisering så att du inte behöver tänka på teckenvariationer eller utfyllnadsregler.

Proffstips

• Koda och avkoda samtidigt: De två sektionerna är oberoende. Du kan skriva text i Kodningsdelen och samtidigt klistra in en separat Base64-sträng i Avkodningsdelen. Använd detta för att jämföra indata och utdata från båda riktningarna sida vid sida.

• URL-säkert för JWT: När du arbetar med JWT-token, aktivera alltid URL-säkert läge. JWT-segment använder den URL-säkra varianten (RFC 7515). Om du klistrar in ett JWT-segment i avkodningsdelen upptäcker verktyget de URL-säkra tecknen automatiskt.

• Ta bort blanksteg före inklistring: Vissa källor till Base64-data innehåller avslutande radbrytningar eller mellanslag. Avkodaren hanterar rensad indata bäst. Om du ser ett "Ogiltig Base64-sträng"-fel, kontrollera om den inklistrade texten har extra blanksteg.

• Ladda ner för stor utdata: För långa Base64-strängar, använd Ladda ner-knapparna istället för Kopiera. Den inbyggda Spara som-dialogrutan låter dig välja var du vill spara filen, och resultatet sparas som en .b64- eller .txt-fil som du kan överföra eller arkivera.

• Ladda upp som alternativ till att skriva: Om du redan har en fil som innehåller texten eller Base64-datan, dra den till uppladdningszonen. Detta är snabbare än att öppna filen, välja allt, kopiera och klistra in — särskilt för stora filer.

• Avkoda först för att kontrollera formatet: Om du får en Base64-sträng och är osäker på om den innehåller text eller binära data, klistra in den i avkodningsdelen. Om utdatan är läsbar text är du klar. Om den innehåller förvrängda tecken eller ersättningsglyfer ( ) var den ursprungliga källan troligen binär (en bild, PDF eller annat icke-textformat).

Alternativ

Det finns flera andra sätt att koda eller avkoda Base64, var och en med olika avvägningar.

För att koda eller avkoda Base64-text med integritet, realtidsfeedback och utan kommandoradskunskaper, erbjuder detta verktyg den bästa användarupplevelsen.

Dataintegritet

Base64-kodaren och avkodaren bearbetar varje tecken helt i din webbläsare. Ingen text du anger överförs till en server, lagras i en databas eller loggas i något system.

All konvertering utförs med JavaScripts inbyggda btoa()- och atob()-funktioner i webbläsarens minne. Sidan innehåller inga analysskript, spårningspixlar eller tredjepartsinbäddningar. Inga cookies, localStorage- eller sessionStorage-poster skapas eller läses.

Efter första sidladdningen fungerar verktyget helt offline. Du kan koppla bort internet och fortsätta koda och avkoda utan avbrott. Verifiera detta genom att använda verktyget i flygplansläge eller genom att inspektera nätverksaktivitet i din webbläsares utvecklingsverktyg — inga förfrågningar lämnar din enhet efter att sidan har laddats.

Felsökning

Tekniska Specifikationer

• Kärnalgoritm: btoa() / atob() insvept med encodeURIComponent / decodeURIComponent för UTF-8-säkerhet
• Standard: RFC 4648 §4 (standard Base64), RFC 4648 §5 (URL-säkert Base64)
• Indatahantering: Automatisk URL-säker teckenkonvertering (- → +, _ → /) och utfyllnadsnormalisering vid avkodning
• Realtidsbearbetning: input-händelseavlyssnare på textfält, avstudsad till cirka en bildruta (16 ms)
• Fil-I/O: FileReader-API för uppladdning, showSaveFilePicker (File System Access API) med <a download>-fallback
• Nedladdningsformat: .b64 (kodad), .txt (avkodad)
• Uppladdningsformat: .txt (Kodningsdelen), .b64 / .txt (Avkodningsdelen)

Prestandabenchmarks

Uppmätt på en medelklass bärbar dator från 2020 (Chrome 120). Prestanda skalar linjärt med indatastorleken. För typiska textnyttolaster under 100 KB är konverteringen praktiskt taget omedelbar.

Webbläsarkompatibilitet

showSaveFilePicker kräver Chromium-baserade webbläsare (Chrome, Edge, Opera, Samsung Internet). I Firefox och Safari faller nedladdningen automatiskt tillbaka på <a download>-metoden.

Integritet och Säkerhet

• Noll dataöverföring: all textbearbetning sker i webbläsarens minne
• Inga cookies, localStorage eller sessionStorage används
• Inga analys- eller spårningsskript på verktygssidan
• Fullt fungerande i offlineläge efter första sidladdningen
• Ingen registrering, inloggning eller API-nycklar krävs

Funktioner

• Koda text till Base64 och avkoda Base64 tillbaka till text med realtidskonvertering
• URL-säkert läge med -_ istället för +/ för webbvänligt Base64 (RFC 4648 §5)
• Alternativ utan utfyllnad för att ta bort avslutande likhetstecken (RFC 4648 §3.2)
• Inbyggd förklaring av Base64-kodningsschemat och .b64-filformatet
• Ladda upp .txt- och .b64-filer med dra-och-släpp-stöd
• Ladda ner resultat som .b64- eller .txt-filer med inbyggd Spara som-dialogruta
• Helt klientsida — inga serveruppladdningar, fungerar offline

Vanliga frågor