> base64 encoder | text | fil <

Skriv eller klistra in din text i INDATA-området ovan. Autokodning är på som standard — Base64-resultatet visas i UTDATA-rutan medan du skriver. Klicka på [ENCODE] eller tryck på Ctrl/Cmd + Enter för att utlösa kodning manuellt. Slå på --url-safe eller --no-padding beroende på var Base64 ska användas (JWT, OAuth, URL:er → båda på). Allt körs lokalt i din webbläsare: inga uppladdningar, inga loggar, inga nätverksbegäranden kopplade till din indata.

Klicka på knappen [upload file] under indataområdet och välj en fil upp till 100 MB. Kodaren läser den med FileReader.readAsArrayBuffer, strömmar bytena genom btoa i 32 KB-block (så att stora filer inte kraschar webbläsaren) och skriver hela Base64 i UTDATA-rutan. För större filer, använd en kommandoradskodare: base64 < input.bin > output.txt (macOS/Linux), eller PowerShell: [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin')).

Om du vill ha Base64 formaterad som en Data URI (t.ex. data:image/png;base64,...), lägg till MIME-typen och ;base64, före utdatan, eller använd vårt dedikerade verktyg Bild till Base64, som ger färdiga Data URI:er för PNG, JPG, GIF, WebP och SVG.

Alla tre är definierade i RFC 4648:

• Standard-Base64 (§4) använder alfabetet A-Z a-z 0-9 + / med =-padding. Utdatalängden är alltid en multipel av 4. Säker för MIME, HTTP Basic Auth och JSON-strängvärden.

• URL-säker Base64 (§5) ersätter + med - och / med _. Krävs när Base64 placeras i URL-sökvägar, frågeparametrar, filnamn eller JWT-segment — standardtecknen +/ skulle annars behöva procentkodas.

• Ingen padding (både §4 och §5, base64url utan padding) tar bort avslutande =-tecken. Längden är inte längre en multipel av 4, men avkodare kan beräkna den ursprungliga längden från resten modulo 4. Används av JWT (base64url enligt RFC 7515), WebAuthn och vissa CBOR/COSE-implementeringar.

Avkodare måste få veta vilken variant de ska förvänta sig — vår Base64-avkodare upptäcker alla tre automatiskt.

Alla större språk och körtider levereras med Base64-kodning. Färdiga kodavsnitt att kopiera och klistra in:

JavaScript (browser):
btoa('Hello') // SGVsbG8=
// För UTF-8:
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // UTF-8-säker

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

Python:
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL-säker, 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=. Använd base64 -w 0 på Linux för att undertrycka radbrytning vid 76 kolumner.

Base64-utdata är ~33 % större än indatan: var 3 indatabytes blir 4 utdatategn. Exakt formel: ceil(n / 3) × 4 inklusive padding, eller ceil(n × 4 / 3) utan. Plus några extra bytes overhead om du radbryter vid 76 kolumner (MIME) eller 64 kolumner (PEM).

Exempel:
• 1 KB binär → ~1,37 KB Base64
• 100 KB bild → ~137 KB Data URI
• 1 MB PDF → ~1,37 MB Base64 i JSON

När man bör undvika Base64:
• Stora filöverföringar: en 10 MB-bild inbäddad som Base64 i HTML blir 13,7 MB tolkad text, blockerar huvudtråden och kan inte cachas separat. Föredra <img src="/assets/photo.png">.
• Prestandakritiska API:er: en 500 KB Base64-nyttolast i JSON tolkas ~2-3× långsammare än en motsvarande binär slutpunkt.
• Som en säkerhetsåtgärd: Base64 är inte kryptering — vem som helst kan avkoda det. Använd AES-GCM eller liknande för konfidentialitet.
• Databas-BLOB:er: lagra råa bytes som BLOB/BYTEA, inte Base64-text, för att spara 33 % lagring och undvika kodnings-/avkodningsrundturer.

JWT (RFC 7515) och OAuth PKCE (RFC 7636) använder båda URL-säker Base64 utan padding, ofta kallad base64url. För att producera den i detta verktyg: aktivera både kryssrutorna --url-safe och --no-padding och koda sedan din text.

Programmatiska motsvarigheter:
• 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)

Vanliga JWT-fält som behöver base64url: de tre punktseparerade segmenten (header, payload, signatur), OAuth PKCE code_verifier/code_challenge, WebAuthn-utmaningar, Web Push-nycklarna p256dh/auth och Googles Request.state-parametrar.

En vanlig bugg är att skicka en JWT med standard-Base64 (+/) — API:er avvisar den som felaktig eftersom + URL-avkodas till ett mellanslag under överföringen.

Ja, med ett förbehåll. Denna kodare producerar Base64-delen av en Data URI — delen efter ;base64,. För att bygga en komplett Data URI, lägg till framför:

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

Vanliga MIME-typer:
• data:image/png;base64,... — PNG-bild
• data:image/jpeg;base64,... — JPEG-bild
• data:image/svg+xml;base64,... — SVG (eller använd data:image/svg+xml;utf8, utan Base64 — oftast mindre)
• data:application/pdf;base64,... — PDF-fil
• data:application/font-woff2;base64,... — teckensnittsinbäddning
• data:text/plain;charset=utf-8;base64,... — Base64-inkapslad text

För bilder och SVG:er ger verktyget Bild till Base64 ut den kompletta Data URI:n redo att klistra in i CSS background-image, inline <img src="..."> eller <object data="...">-taggar.

Storleksvarning: Data URI:er över 20-30 KB skadar LCP (Largest Contentful Paint) eftersom webbläsaren inte kan förladda dem — håll inline Base64-bilder små och föredra vanlig <img> med loading="lazy" för större tillgångar.

Ja — inget lämnar din webbläsare. Kodaren körs helt i JavaScript med de inbyggda API:erna btoa(), TextEncoder och FileReader. Det finns inga nätverksanrop på indatainnehållet, ingen telemetri, ingen loggning, ingen tredjepartsanalys av det du kodar. Du kan öppna Network-fliken i DevTools medan du kodar och observera noll relaterade begäranden.

Dock är Base64 inte kryptering — det är en reversibel kodning, och vem som helst med utdatan kan avkoda den. Så:
• Klistra inte in produktionshemligheter i chatt, skärmdumpar eller loggar, ens i kodad form.
• För HTTP Basic Auth är Base64-headern Authorization: Basic bara säker över TLS (HTTPS). Över HTTP i klartext är den trivialt avlyssningsbar.
• För verklig konfidentialitet, använd AES-GCM, age, sops eller ett KMS — och Base64-koda sedan chiffertexten för transport vid behov.

För strikta riktlinjer mot dataexfiltrering, spara denna sida offline (Cmd/Ctrl + S). Kodaren fungerar helt isolerad efter en laddning, eftersom det inte finns något serverberoende.

Kodaren stöder filer upp till 100 MB via den hårda gränsen i filhanteraren — tillräckligt stor för de flesta bilder, PDF-filer, ZIP-arkiv och även korta videor. Prestandamål:

• < 1 MB: kodningen slutförs på <50 ms, ingen UI-frysning.
• 1 – 10 MB: 100-500 ms beroende på CPU. Webbläsaren förblir responsiv eftersom vi kodar i 32 KB-block.
• 10 – 100 MB: 2-15 sekunder. Utdatatextrutan kan släpa något när du klistrar in/scrollar så enorma Base64-strängar. Överväg att ladda ner utdatan som en .txt-fil från DevTools vid behov.
• > 100 MB: blockerad — webbläsarens minnesoverhead (indatabytes + binär sträng + Base64-sträng ≈ 3-4× filstorleken) riskerar flikkrascher. Använd:

# 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))

För streaming-/multi-GB-arbetsflöden, se koda stora filer till Base64 för en blockbaserad metod med Node.js/Python som undviker att läsa in allt i minnet.

Denna kodare använder UTF-8, samma kodning som används av det moderna webben, JSON, Linux, macOS och nästan alla programmeringsspråk som standard. Under huven körs text genom new TextEncoder().encode(input), som alltid producerar UTF-8-bytes, och först därefter Base64-kodas.

Varför detta är viktigt: den äldre JavaScript-funktionen btoa() hanterar endast Latin-1 och kastar InvalidCharacterError vid tecken som é, 中 eller 😀. Vår wrapper hanterar UTF-8-konverteringen åt dig, så att emoji, kinesiska, japanska, koreanska, arabiska, kyrilliska och vilken Unicode-kodpunkt som helst kodas korrekt.

Om du behöver en annan kodning:
• UTF-16 LE (Windows-native): sällsynt — vanligtvis ett tecken på äldre interoperabilitet. Använd ändå new TextEncoder({ fatal: true }).encode(s) och konvertera uppströms.
• ISO-8859-1 / Latin-1: mappa manuellt kodpunkterna 0-255 till bytes före kodning.
• GB18030, Shift_JIS, EUC-KR: använd ett bibliotek som iconv-lite i Node.js för att transkoda först.

En subtil fallgrop: om dina källdata redan är i en icke-UTF-8-kodning (t.ex. vid läsning av en äldre MySQL-dump), avkoda dem först med rätt codec, koda sedan om till UTF-8 innan du tillämpar Base64 — annars bevarar den avkodade Base64:an mojibaken.