> base64 encoder | tekst | fil <

Skriv eller lim inn teksten din i INNDATA-området over. Autokoding er på som standard — Base64-resultatet vises i UTDATA-boksen mens du skriver. Klikk på [ENCODE] eller trykk Ctrl/Cmd + Enter for å utløse koding manuelt. Slå på --url-safe eller --no-padding avhengig av hvor Base64 skal brukes (JWT, OAuth, URL-er → begge på). Alt kjører lokalt i nettleseren din: ingen opplastinger, ingen logger, ingen nettverksforespørsler knyttet til inndataene dine.

Klikk på [upload file]-knappen under inndataområdet og velg en fil opptil 100 MB. Koderen leser den med FileReader.readAsArrayBuffer, streamer bytene gjennom btoa i 32 KB-biter (slik at store filer ikke krasjer nettleseren) og skriver hele Base64 i UTDATA-boksen. For større filer kan du bruke en kommandolinjekoder: base64 < input.bin > output.txt (macOS/Linux), eller PowerShell: [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin')).

Hvis du vil ha Base64 formatert som en Data URI (f.eks. data:image/png;base64,...), sett MIME-typen og ;base64, foran utdataene, eller bruk vårt dedikerte Bilde til Base64-verktøy, som gir klar-til-å-lime-inn Data-URI-er for PNG, JPG, GIF, WebP og SVG.

Alle tre er definert i RFC 4648:

• Standard-Base64 (§4) bruker alfabetet A-Z a-z 0-9 + / med =-padding. Utdatalengden er alltid et multiplum av 4. Trygt for MIME, HTTP Basic Auth og JSON-strengverdier.

• URL-sikker Base64 (§5) erstatter + med - og / med _. Påkrevd når Base64 plasseres i URL-stier, spørringsparametere, filnavn eller JWT-segmenter — standardtegnene +/ ville ellers måtte prosentkodes.

• Uten padding (både §4 og §5, base64url uten padding) fjerner avsluttende =-tegn. Lengden er ikke lenger et multiplum av 4, men dekodere kan beregne den opprinnelige lengden fra resten modulo 4. Brukes av JWT (base64url iht. RFC 7515), WebAuthn og noen CBOR/COSE-implementasjoner.

Dekodere må få beskjed om hvilken variant de skal forvente — vår Base64-dekoder oppdager alle tre automatisk.

Alle store språk og kjøretidsmiljøer leveres med Base64-koding. Klar-til-å-kopiere-utdrag:

JavaScript (browser):
btoa('Hello') // SGVsbG8=
// For UTF-8:
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // UTF-8-sikker

Node.js:
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL-sikker, ingen padding

Python:
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL-sikker, ingen padding

PHP: base64_encode('Hello')
Ruby: Base64.strict_encode64('Hello') / Base64.urlsafe_encode64('Hello')
Go: base64.StdEncoding.EncodeToString([]byte("Hello")) / base64.URLEncoding.EncodeToString(...) / base64.RawURLEncoding.EncodeToString(...) (ingen padding)
Java: Base64.getEncoder().encodeToString("Hello".getBytes(StandardCharsets.UTF_8))
C#: Convert.ToBase64String(Encoding.UTF8.GetBytes("Hello"))
Rust: base64::engine::general_purpose::STANDARD.encode("Hello")

Shell (macOS/Linux): echo -n 'Hello' | base64 → SGVsbG8=. Bruk base64 -w 0 på Linux for å undertrykke 76-kolonners linjebryting.

Base64-utdata er ~33 % større enn inndataen: hver 3 inndatabytes blir til 4 utdatategn. Eksakt formel: ceil(n / 3) × 4 inkludert padding, eller ceil(n × 4 / 3) uten. Pluss noen ekstra bytes overhead hvis du linjebryter ved 76 kolonner (MIME) eller 64 kolonner (PEM).

Eksempler:
• 1 KB binær → ~1,37 KB Base64
• 100 KB bilde → ~137 KB Data URI
• 1 MB PDF → ~1,37 MB Base64 i JSON

Når Base64 bør unngås:
• Store filoverføringer: et 10 MB-bilde innebygd som Base64 i HTML blir til 13,7 MB parset tekst, blokkerer hovedtråden og kan ikke caches separat. Foretrekk <img src="/assets/photo.png">.
• Ytelseskritiske API-er: en 500 KB Base64-nyttelast i JSON parses ~2-3× tregere enn et tilsvarende binært endepunkt.
• Som et sikkerhetstiltak: Base64 er ikke kryptering — hvem som helst kan dekode det. Bruk AES-GCM eller lignende for konfidensialitet.
• Database-BLOB-er: lagre rå bytes som BLOB/BYTEA, ikke Base64-tekst, for å spare 33 % lagringsplass og unngå kode/dekode-rundturer.

JWT (RFC 7515) og OAuth PKCE (RFC 7636) bruker begge URL-sikker Base64 uten padding, ofte kalt base64url. For å produsere det i dette verktøyet: aktiver både --url-safe- og --no-padding-avmerkingsboksene, og kod deretter teksten din.

Programmatiske ekvivalenter:
• JavaScript: btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
• Node.js: Buffer.from(s).toString('base64url')
• Python: base64.urlsafe_b64encode(s.encode()).decode().rstrip('=')
• Go: base64.RawURLEncoding.EncodeToString([]byte(s))
• Java: Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

Vanlige JWT-felt som trenger base64url: de tre punktdelte segmentene (header, payload, signatur), OAuth PKCE code_verifier/code_challenge, WebAuthn-utfordringer, Web Push-nøklene p256dh/auth og Googles Request.state-parametere.

En vanlig feil er å sende en JWT med standard-Base64 (+/) — API-er avviser den som feilformet fordi + blir URL-dekodet til et mellomrom underveis.

Ja, med ett forbehold. Denne koderen produserer Base64-delen av en Data URI — delen etter ;base64,. For å bygge en komplett Data URI, sett foran:

data:<mime-type>;base64,<encoded-output>

Vanlige MIME-typer:
• data:image/png;base64,... — PNG-bilde
• data:image/jpeg;base64,... — JPEG-bilde
• data:image/svg+xml;base64,... — SVG (eller bruk data:image/svg+xml;utf8, uten Base64 — vanligvis mindre)
• data:application/pdf;base64,... — PDF-fil
• data:application/font-woff2;base64,... — innebygd skrift
• data:text/plain;charset=utf-8;base64,... — Base64-innpakket tekst

For bilder og SVG-er gir Bilde til Base64-verktøyet ut den komplette Data URI-en klar til å limes inn i CSS background-image, inline <img src="..."> eller <object data="...">-tagger.

Størrelsesadvarsel: Data-URI-er over 20-30 KB skader LCP (Largest Contentful Paint) fordi nettleseren ikke kan forhåndslaste dem — hold inline Base64-bilder små, og foretrekk vanlig <img> med loading="lazy" for større ressurser.

Ja — ingenting forlater nettleseren din. Koderen kjører helt i JavaScript ved hjelp av de native API-ene btoa(), TextEncoder og FileReader. Det er ingen nettverkskall på inndatainnholdet, ingen telemetri, ingen logging, ingen tredjepartsanalyse på det du koder. Du kan åpne nettverksfanen i DevTools mens du koder og observere null relaterte forespørsler.

Imidlertid er Base64 ikke kryptering — det er en reversibel koding, og hvem som helst med utdataene kan dekode det. Så:
• Ikke lim inn produksjonshemmeligheter i chat, skjermbilder eller logger, selv i kodet form.
• For HTTP Basic Auth er Base64-headeren Authorization: Basic bare trygg over TLS (HTTPS). Over klartekst-HTTP er den trivielt avlyttbar.
• For ekte konfidensialitet, bruk AES-GCM, age, sops eller et KMS — og Base64-kod deretter chifferteksten for transport ved behov.

For strenge retningslinjer mot dataeksfiltrering kan du lagre denne siden offline (Cmd/Ctrl + S). Koderen fungerer helt isolert etter én innlasting, siden det ikke finnes noen serveravhengighet.

Koderen støtter filer opptil 100 MB via den harde grensen i filhåndtereren — stort nok for de fleste bilder, PDF-er, ZIP-arkiver og til og med korte videoer. Ytelsesmål:

• < 1 MB: koding fullføres på <50 ms, ingen UI-frysing.
• 1 – 10 MB: 100-500 ms avhengig av CPU. Nettleseren forblir responsiv fordi vi koder i 32 KB-biter.
• 10 – 100 MB: 2-15 sekunder. Utdata-tekstområdet kan henge litt når du limer inn/ruller slike enorme Base64-strenger. Vurder å laste ned utdataene som en .txt-fil fra DevTools ved behov.
• > 100 MB: blokkert — nettleserens minneoverhead (inndatabytes + binær streng + Base64-streng ≈ 3-4× filstørrelsen) risikerer fanekrasj. Bruk:

# macOS / Linux
base64 -i huge.bin -o huge.b64

# Windows PowerShell
$bytes = [IO.File]::ReadAllBytes('huge.bin')
[IO.File]::WriteAllText('huge.b64', [Convert]::ToBase64String($bytes))

For streaming-/multi-GB-arbeidsflyter, se koding av store filer til Base64 for en chunked tilnærming med Node.js/Python som unngår å laste alt inn i minnet.

Denne koderen bruker UTF-8, den samme kodingen som brukes av det moderne nettet, JSON, Linux, macOS og nesten alle programmeringsspråk som standard. Under panseret føres tekst gjennom new TextEncoder().encode(input), som alltid produserer UTF-8-bytes, og først deretter Base64-kodes.

Hvorfor dette er viktig: den eldre JavaScript-funksjonen btoa() håndterer kun Latin-1 og kaster InvalidCharacterError på tegn som é, 中 eller 😀. Vår wrapper håndterer UTF-8-konverteringen for deg, slik at emoji, kinesisk, japansk, koreansk, arabisk, kyrillisk og ethvert Unicode-kodepunkt kodes korrekt.

Hvis du trenger en annen koding:
• UTF-16 LE (Windows-native): sjelden — vanligvis et tegn på legacy-interop. Bruk likevel new TextEncoder({ fatal: true }).encode(s) og konverter oppstrøms.
• ISO-8859-1 / Latin-1: tilordne kodepunktene 0-255 til bytes manuelt før koding.
• GB18030, Shift_JIS, EUC-KR: bruk et bibliotek som iconv-lite i Node.js for å transkode først.

En subtil felle: hvis kildedataene dine allerede er i en ikke-UTF-8-koding (f.eks. ved lesing av en legacy-MySQL-dump), dekod dem først med riktig kodek, og kod dem deretter om til UTF-8 før du bruker Base64 — ellers vil den dekodede Base64-en bevare mojibaken.