Base64-koding forklart: Når og hvorfor bruke det

Du har sannsynligvis sett Base64 før — de lange, rare strengene som SGVsbG8gV29ybGQ=. De dukker opp i e-poster, data-URI-er, API-nyttelaster og JWT-er. Men hva er egentlig Base64, og når bør du bruke det? La oss oppklare dette.

Hva Base64 gjør (på vanlig norsk)

Base64 tar hvilke som helst data — tekst, bilder, filer, hva som helst — og konverterer det til en streng som bare bruker 64 "trygge" ASCII-tegn: A-Z, a-z, 0-9, + og /. Tegnet = på slutten er utfylling.

Hvorfor? Fordi ikke alle systemer håndterer rå binærdata. E-post ble designet for tekst. JSON støtter ikke binært. URL-parametere kan ikke inneholde vilkårlige bytes. Base64 er broen som lar deg presse binærdata gjennom rene tekstkanaler.

Hvordan det fungerer under panseret

Algoritmen er overraskende enkel. Den tar 3 byte med inndata (24 bit), deler dem i 4 grupper på 6 bit hver, og kobler hver gruppe til ett av de 64 tegnene. Her er et raskt eksempel:

Inndata: Hi (2 byte: 72, 105)

Binært: 01001000 01101001 + utfyllingsnuller

Delt i 6-bit-grupper: 010010 000110 100100

Koblet til Base64-alfabetet: SGk=

Matematikken betyr at Base64-utdata alltid er omtrent 33% større enn inndataen. Det er avveiningen for trygg tekstoverføring. RFC 4648-spesifikasjonen definerer den nøyaktige algoritmen hvis du vil ha alle detaljene.

Når du bør bruke Base64

Bygge inn små bilder i HTML/CSS: I stedet for å la nettleseren hente en separat fil, kan du legge inn et lite ikon inline: . Dette sparer en HTTP-forespørsel. Flott for ikoner under 2-3KB.

Sende binærdata i JSON-API-er: JSON kan ikke lagre rå bytes. Trenger du å laste opp en fil via en JSON-API? Base64-kod den:

E-postvedlegg: Dette er bokstavelig talt det Base64 ble designet for. MIME-koding bruker Base64 for å bygge inn binære vedlegg i tekstbaserte e-postmeldinger.

JWT-er og autentiseringstokener: JSON Web Tokens bruker Base64URL-koding (en URL-trygg variant) for sine header- og payload-seksjoner.

Lagre binærdata i tekstfelter: Databasens tekstkolonner, miljøvariabler, konfigurasjonsfiler — Base64 lar deg plassere binærdata hvor som helst tekst hører hjemme.

Når du IKKE bør bruke Base64

• Store filer. Den 33% størrelsesøkningen gjør virkelig vondt med store filer. Et 10MB-bilde blir 13,3MB i Base64. Bruk multipart-form-opplasting i stedet.
• Sikkerhet. Base64 er ikke kryptering. Det er trivielt reverserbart. Bruk det aldri til å "gjemme" passord eller sensitiv data. Hvem som helst kan dekode cGFzc3dvcmQ= tilbake til password på sekunder.
• Store innebygde bilder. For bilder over ~5KB vil en separat fil med skikkelig HTTP-caching yte bedre enn en Base64-data-URI.

Den URL-trygge varianten

Standard Base64 bruker + og /, som har spesiell betydning i URL-er. Base64URL-varianten erstatter dem med - og _. Du vil se dette i JWT-er og overalt hvor Base64-data vises i URL-er.

Raske kodeeksempler

Slik koder og dekoder du Base64 i de vanligste språkene:

Legg merke til at JavaScripts nettleser-funksjon btoa() bare fungerer med ASCII-strenger. Hvis du trenger å kode Unicode-tekst, må du ta et ekstra steg gjennom TextEncoder først — det snubler mange utviklere.

Vanlige feil med Base64

Her er fallgruvene jeg ser utviklere gå i oftest:

1. Anta at Base64 er kryptering. Jeg kan ikke understreke dette nok. Jeg har sett produksjonskodebaser som Base64-koder API-nøkler og passord, og tror de er "beskyttet". Hvem som helst med en nettleserkonsoll kan dekode dem umiddelbart. Hvis du trenger å beskytte data, bruk ekte kryptering (AES, RSA) eller hashing (bcrypt, argon2).

2. Ikke håndtere utfylling riktig. Noen implementasjoner fjerner de avsluttende =-tegnene, noe som kan forårsake dekodingsfeil i strenge parsere. Hvis du sender Base64 mellom systemer, bli enig om utfylling er inkludert eller ikke.

3. Bruke standard Base64 i URL-er. + og / tegnene i standard Base64 vil ødelegge URL-er. Bruk alltid den URL-trygge varianten (Base64URL) når du bygger inn kodet data i spørringsparametere eller banesegmenter.

4. Base64-kode store filer i JSON-nyttelaster. En 5MB-fil blir nesten 7MB etter Base64-koding, og hele den strengen må holdes i minnet. For alt større enn noen få KB, bruk multipart/form-data i stedet.

Base64-tegnsett hurtigreferanse

Praktisk eksempel: Bygge inn fonter i CSS

En vanlig bruk av Base64 som du kanskje ikke tenker på er å bygge inn egendefinerte fonter direkte i CSS-filer. Dette unngår en ekstra HTTP-forespørsel for fontfilen:

Denne teknikken fungerer bra for små ikonfonter (under 10-15KB). For større fontfiler er det bedre å servere dem separat slik at nettleseren kan cache dem uavhengig.

Base64 vs andre kodingsmetoder

Base64 er ikke den eneste måten å representere binærdata som tekst. Det finnes flere alternativer, og hvert har sitt sterke punkt. La oss sammenligne de viktigste.

Heksakoding (Base16): Den enkleste tilnærmingen — hver byte blir to heksadesimale tegn (0-9, A-F). Så Hi blir 4869. Det er dødt enkelt og menneskelesbart, men utdataene er 100% større enn inndataen (dobbelt størrelse). Du ser heks overalt: fargekoder (#FF5733), SHA-hasher, MAC-adresser og debug-utdata.

Base32: Bruker 32 tegn (A-Z og 2-7). Utdataene er omtrent 60% større enn inndataen. Du har sannsynligvis sett det uten å vite det — de 6-sifrede kodene fra Google Authenticator og andre TOTP/2FA-apper bruker Base32-kodede hemmeligheter under panseret. Det er også ufølsomt for store/små bokstaver, noe som gjør det flott for situasjoner der brukere må skrive inn kodede data manuelt.

ASCII85 / Base85: Bruker 85 utskrivbare ASCII-tegn og produserer utdata som bare er omtrent 25% større enn inndataen. Det er mer effektivt enn Base64. Git bruker en variant av Base85 i sitt binære patch-format (packfiles), og Adobe PostScript- og PDF-filer bruker ASCII85-koding internt. Ulempen? Det bruker tegn som {, } og anførselstegn som kan forårsake hodepine i JSON, XML og URL-er.

Her er en sammenligning av koding av den samme 100-byte inndataen:

Hvorfor vinner Base64 i de fleste tilfeller? Det treffer det perfekte punktet: rimelig overhead, bredt støttet på tvers av alle språk og plattformer, og det unngår de fleste spesialtegn som forårsaker problemer i vanlige formater. Base85 er mer kompakt, men mindre universelt støttet og vanskeligere å bruke trygt i strukturerte tekstformater.

Base64 i autentiseringsflyter

En av de mest utbredte (og mest misforståtte) bruksområdene for Base64 er HTTP Basic Authentication. Når du sender et brukernavn og passord via Basic Auth, setter nettleseren dem sammen med kolon og Base64-koder resultatet.

Her er hva som skjer under panseret når du logger inn med brukernavn admin og passord secret123:

Serveren mottar den headeren, Base64-dekoder den, deler på kolon og sjekker legitimasjonen. Enkelt, ikke sant? Men her er det kritiske poenget: dette er IKKE sikkert uten HTTPS. Den Base64-strengen er trivielt reverserbar — hvem som helst som fanger opp forespørselen kan dekode YWRtaW46c2VjcmV0MTIz og få passordet ditt på under et sekund. RFC 7617-spesifikasjonen for Basic Auth advarer eksplisitt om dette.

Base64 dukker også opp i andre autentiseringskontekster. OAuth 2.0 access-tokener og refresh-tokener er ofte Base64-kodet (selv om dette er en implementasjonsdetalj, ikke et krav). Mange API-nøkler fra tjenester som AWS, Stripe og Google Cloud er Base64-kodede strenger. Igjen, kodingen er for trygg transport — ikke for sikkerhet. Send dem alltid over HTTPS og lagre dem sikkert.

Data-URI-er i dybden

Vi nevnte data-URI-er kort tidligere, men de fortjener en dypere titt. En data-URI lar deg bygge inn filinnhold direkte i HTML, CSS eller JavaScript — ingen ekstern HTTP-forespørsel nødvendig. Den fullstendige syntaksen er:

mediatype er en standard MIME-type, ;base64-flagget forteller nettleseren at dataene er Base64-kodet (uten det antas dataene å være URL-kodet tekst), og er det faktiske innholdet.

Her er eksempler for ulike medietyper:

PNG-bilde (vanligst):

Inline SVG (ingen Base64 nødvendig!):

Legg merke til at SVG-er allerede er tekst, så du kan URL-kode dem i stedet for å Base64-kode dem. Dette er faktisk mindre fordi du slipper 33%-overheaden. Smarte utviklere bruker dette trikset for enkle SVG-ikoner.

PDF-dokument:

Lydfil:

Om nettleserbegrensninger: selv om data-URI-spesifikasjonen på MDN ikke definerer en maksimal størrelse, setter nettleserne sine egne grenser. Chrome begrenser data-URI-er til rundt 2MB i navigasjonskontekster (som iframes og toppnivåsider). Firefox er mer sjenerøs. For CSS-bakgrunnsbilder og inline-bilder er den praktiske grensen brukernes tålmodighet — en 500KB Base64-streng i CSS-filen din er teknisk gyldig, men vil fullstendig ødelegge lastetidene.

Ytelsespåvirkning: Når Base64 skader

La oss snakke om reelle tall, fordi "33% overhead" høres abstrakt ut til du ser virkningen i praksis.

Båndbreddekostnad: Et 50KB-bilde blir ~67KB etter Base64-koding. Det er 17KB ekstra per bilde. Gang det med en side med 20 inline-ikoner og du sender 340KB med unødvendig data. For referanse er det mer enn hele HTML-en til de fleste nettsider.

Minnebruk: Når du Base64-koder et bilde og bygger det inn i HTML eller CSS, må hele den kodede strengen holdes i minnet som del av DOM-en eller stilarket. Nettleseren dekoder den så tilbake til binært, så i et kort øyeblikk holder du både den kodede og dekodede versjonen. For et 1MB-bilde er det omtrent 2,33MB bare for den kodede strengen, pluss 1MB for det dekodede binæret — over 3x den opprinnelige filstørrelsen.

Parsetid: Base64-strenger inne i HTML eller CSS må parses som del av disse dokumentene. En stor data-URI gjør hele CSS-filen eller HTML-dokumentet tregere å parse. Ifølge web.devs bildeoptimaliseringsguide bør inline-bilder generelt være under 2-4KB for å gi en netto ytelsesfordel.

Cache-ineffektivitet: Dette er det utviklere overser mest. Når du serverer et bilde som en separat fil, cacher nettleseren det uavhengig — påfølgende sideinnlastinger hopper over nedlastingen helt. Men når du Base64-koder det samme bildet inne i CSS-filen din, blir det en del av CSS-en. Hvis du endrer noe annet i CSS-en, laster nettleseren ned hele filen på nytt, inkludert Base64-bildedataene som ikke endret seg. Du mister granulær caching.

Her er en grov benchmark for perspektiv:

Tommelfingerregelen: Base64-inline alt under 2-4KB. Server alt annet som en separat fil. Med HTTP/2 og HTTP/3 er kostnaden for ekstra forespørsler minimal, så terskelen har blitt enda lavere gjennom årene.

Base64 i ulike programmeringsspråk

Vi dekket JavaScript og Python tidligere. Slik håndterer du Base64 i andre populære språk — hvert er bare et par linjer:

Legg merke til at hvert språk har Base64 i standardbiblioteket sitt — ingen tredjepartspakker nødvendig. Det er et bevis på hvor grunnleggende denne kodingen er. Merk også at Ruby har strict_encode64 (ingen linjeskift) og encode64 (setter inn linjeskift hvert 60. tegn, i tråd med den opprinnelige MIME-standarden). De fleste moderne brukstilfeller vil ha strict-versjonen.

Historien om Base64

Base64 dukket ikke opp fra ingensteds. Historien er knyttet til e-postens historie, og å forstå den forklarer mange av designvalgene.

I internettets tidlige dager ble e-post (SMTP) designet for å håndtere bare 7-bit ASCII-tekst — 128 tegn, og det var det. Dette var greit for engelsk tekst, men helt ubrukelig for å sende bilder, dokumenter, eller til og med tekst på andre språk enn engelsk. Du kunne rett og slett ikke sende binærdata via e-post.

Den første formelle spesifikasjonen av Base64 dukket opp i RFC 1421 i 1993, som del av Privacy Enhanced Mail (PEM)-standarden. Ideen var grei: konvertere binærdata til et undersett av ASCII som ville overleve ethvert tekstbasert transportsystem uten korrupsjon.

Så kom RFC 2045 i 1996, som definerte MIME (Multipurpose Internet Mail Extensions). MIME standardiserte hvordan e-postvedlegg fungerer, og Base64 var dens primære koding for binært innhold. Derfor ser du fortsatt Content-Transfer-Encoding: base64-headere i rå e-postmeldinger i dag.

Kodingen ble forbedret igjen i RFC 4648 (2006), som ble den definitive referansen. Denne RFC-en introduserte også den URL-trygge varianten (Base64URL) og klargjorde kantilfeller rundt utfylling. MDN Base64-ordlistesiden er et godt utgangspunkt hvis du vil utforske spesifikasjonen uten å lese rå RFC-er.

Det som er fascinerende er at Base64 ble født fra en begrensning — 7-bit e-post — som ikke lenger eksisterer. Moderne SMTP støtter 8-bit og binær overføring. Likevel har Base64 levd langt forbi sitt opprinnelige formål, og funnet nytt liv i web-API-er, JWT-er, data-URI-er og utallige andre kontekster. Det er en av de teknologiene som løste et problem så godt at folk fortsetter å finne nye problemer for den å løse.

Prøv det selv

Vil du se Base64 i aksjon? Lim inn tekst eller en fil i vår Base64 Encoder for å se den kodede utdataen umiddelbart. Trenger du å dekode noe? Base64 Decoder ordner det. Og hvis du jobber med Base64-kodede bilder, lar vårt Base64 to Image-verktøy deg forhåndsvise dem direkte i nettleseren.