> base64 encoder | tekst | fil <

Skriv eller indsæt din tekst i INPUT-området ovenfor. Auto-encode er slået til som standard — Base64-resultatet vises i OUTPUT-feltet, mens du skriver. Klik på [ENCODE] eller tryk på Ctrl/Cmd + Enter for at udløse kodning manuelt. Slå --url-safe eller --no-padding til afhængigt af, hvor Base64 skal bruges (JWT, OAuth, URL'er → begge til). Alt kører lokalt i din browser: ingen uploads, ingen logfiler, ingen netværksanmodninger knyttet til dit input.

Klik på knappen [upload file] under input-området og vælg en fil op til 100 MB. Encoderen læser den med FileReader.readAsArrayBuffer, streamer bytes gennem btoa i 32 KB-chunks (så store filer ikke får browseren til at gå ned) og skriver hele Base64 i OUTPUT-feltet. Til større filer kan du bruge en kommandolinje-encoder: base64 < input.bin > output.txt (macOS/Linux) eller PowerShell: [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin')).

Hvis du vil have Base64 formateret som en Data URI (f.eks. data:image/png;base64,...), så sæt MIME-typen og ;base64, foran outputtet, eller brug vores dedikerede Billede til Base64-værktøj, der leverer klar-til-indsætning Data URI'er for PNG, JPG, GIF, WebP og SVG.

Alle tre er defineret i RFC 4648:

• Standard-Base64 (§4) bruger alfabetet A-Z a-z 0-9 + / med =-padding. Output-længden er altid et multiplum af 4. Sikker til MIME, HTTP Basic Auth og JSON-strengværdier.

• URL-sikker Base64 (§5) erstatter + med - og / med _. Påkrævet, når Base64 placeres i URL-stier, query-parametre, filnavne eller JWT-segmenter — standardtegnene +/ ville ellers skulle procentkodes.

• No-padding (både §4 og §5, base64url uden padding) fjerner afsluttende =-tegn. Længden er ikke længere et multiplum af 4, men decodere kan beregne den oprindelige længde ud fra resten modulo 4. Bruges af JWT (base64url iflg. RFC 7515), WebAuthn og nogle CBOR/COSE-implementeringer.

Decodere skal have besked om, hvilken variant de skal forvente — vores Base64-decoder registrerer alle tre automatisk.

Alle større sprog og runtimes leveres med Base64-kodning. Klar-til-kopiér-uddrag:

JavaScript (browser):
btoa('Hello') // SGVsbG8=
// Til 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=. Brug base64 -w 0 på Linux for at undertrykke 76-kolonners linjeombrydning.

Base64-output er ~33 % større end inputtet: hver 3 input-bytes bliver til 4 output-tegn. Eksakt formel: ceil(n / 3) × 4 inklusive padding, eller ceil(n × 4 / 3) uden. Plus et par bytes ekstra overhead, hvis du linjeombryder ved 76 kolonner (MIME) eller 64 kolonner (PEM).

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

Hvornår man bør undgå Base64:
• Store filoverførsler: et 10 MB-billede indlejret som Base64 i HTML bliver til 13,7 MB parset tekst, blokerer hovedtråden og kan ikke caches separat. Foretræk <img src="/assets/photo.png">.
• Ydeevnekritiske API'er: en 500 KB Base64-payload i JSON parses ~2-3× langsommere end et tilsvarende binært endpoint.
• Som en sikkerhedsforanstaltning: Base64 er ikke kryptering — alle kan afkode det. Brug AES-GCM eller lignende til fortrolighed.
• Database-BLOB'er: gem rå bytes som BLOB/BYTEA, ikke Base64-tekst, for at spare 33 % lagerplads og undgå kode/afkode-rundture.

JWT (RFC 7515) og OAuth PKCE (RFC 7636) bruger begge URL-sikker Base64 uden padding, ofte kaldet base64url. For at producere det i dette værktøj: aktivér både --url-safe- og --no-padding-afkrydsningsfelterne, og kod derefter din tekst.

Programmatiske ækvivalenter:
• 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)

Almindelige JWT-felter, der kræver base64url: de tre punktadskilte segmenter (header, payload, signatur), OAuth PKCE code_verifier/code_challenge, WebAuthn-challenges, Web Push-nøglerne p256dh/auth og Googles Request.state-parametre.

En almindelig fejl er at sende en JWT med standard-Base64 (+/) — API'er afviser den som fejlbehæftet, fordi + bliver URL-afkodet til et mellemrum undervejs.

Ja, med ét forbehold. Denne encoder producerer Base64-delen af en Data URI — delen efter ;base64,. For at bygge en komplet Data URI skal du sætte foran:

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

Almindelige MIME-typer:
• data:image/png;base64,... — PNG-billede
• data:image/jpeg;base64,... — JPEG-billede
• data:image/svg+xml;base64,... — SVG (eller brug data:image/svg+xml;utf8, uden Base64 — som regel mindre)
• data:application/pdf;base64,... — PDF-fil
• data:application/font-woff2;base64,... — skrifttype-embed
• data:text/plain;charset=utf-8;base64,... — Base64-indpakket tekst

Til billeder og SVG'er udsender Billede til Base64-værktøjet den komplette Data URI klar til at indsætte i CSS background-image, inline <img src="..."> eller <object data="...">-tags.

Størrelsesadvarsel: Data URI'er over 20-30 KB skader LCP (Largest Contentful Paint), fordi browseren ikke kan forindlæse dem — hold inline Base64-billeder små, og foretræk almindelig <img> med loading="lazy" til større aktiver.

Ja — intet forlader din browser. Encoderen kører udelukkende i JavaScript ved hjælp af de native API'er btoa(), TextEncoder og FileReader. Der er ingen netværkskald på inputindholdet, ingen telemetri, ingen logning, ingen tredjeparts-analytics på det, du koder. Du kan åbne netværksfanen i DevTools, mens du koder, og observere nul relaterede anmodninger.

Men Base64 er ikke kryptering — det er en reversibel kodning, og enhver med outputtet kan afkode det. Så:
• Indsæt ikke produktionshemmeligheder i chat, skærmbilleder eller logfiler, selv i kodet form.
• Til HTTP Basic Auth er Base64-headeren Authorization: Basic kun sikker over TLS (HTTPS). Over almindelig HTTP er den trivielt aflyttelig.
• Til ægte fortrolighed skal du bruge AES-GCM, age, sops eller et KMS — og derefter Base64-kode chifferteksten til transport efter behov.

Til strenge dataudsivningspolitikker kan du gemme denne side offline (Cmd/Ctrl + S). Encoderen fungerer fuldstændigt isoleret efter én indlæsning, da der ikke er nogen serverafhængighed.

Encoderen understøtter filer op til 100 MB via den hårde grænse i fil-handleren — stort nok til de fleste billeder, PDF'er, ZIP-arkiver og endda korte videoer. Ydeevnemål:

• < 1 MB: kodning fuldføres på <50 ms, ingen UI-frysning.
• 1 – 10 MB: 100-500 ms afhængigt af CPU. Browseren forbliver responsiv, fordi vi koder i 32 KB-chunks.
• 10 – 100 MB: 2-15 sekunder. Output-tekstfeltet kan lagge en smule, når du indsætter/scroller så enorme Base64-strenge. Overvej at downloade outputtet som en .txt-fil fra DevTools efter behov.
• > 100 MB: blokeret — browserens hukommelses-overhead (input-bytes + binær streng + Base64-streng ≈ 3-4× filstørrelsen) risikerer fane-nedbrud. Brug:

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

Til streaming/multi-GB-arbejdsgange, se kodning af store filer til Base64 for en chunked tilgang med Node.js/Python, der undgår at indlæse alt i hukommelsen.

Denne encoder bruger UTF-8, den samme kodning, som bruges af det moderne web, JSON, Linux, macOS og næsten alle programmeringssprog som standard. Under motorhjelmen ledes tekst gennem new TextEncoder().encode(input), som altid producerer UTF-8-bytes, og først derefter Base64-kodes.

Hvorfor dette betyder noget: den ældre JavaScript-funktion btoa() håndterer kun Latin-1 og kaster InvalidCharacterError ved tegn som é, 中 eller 😀. Vores wrapper håndterer UTF-8-konverteringen for dig, så emoji, kinesisk, japansk, koreansk, arabisk, kyrillisk og ethvert Unicode-kodepunkt kodes korrekt.

Hvis du har brug for en anden kodning:
• UTF-16 LE (Windows-native): sjælden — som regel et tegn på legacy-interop. Brug alligevel new TextEncoder({ fatal: true }).encode(s) og konvertér opstrøms.
• ISO-8859-1 / Latin-1: kortlæg manuelt kodepunkterne 0-255 til bytes før kodning.
• GB18030, Shift_JIS, EUC-KR: brug et bibliotek som iconv-lite i Node.js til at transkode først.

En subtil faldgrube: hvis dine kildedata allerede er i en ikke-UTF-8-kodning (f.eks. ved læsning af et legacy-MySQL-dump), så afkod dem først med den korrekte codec, og genkod derefter til UTF-8, før du anvender Base64 — ellers bevarer den afkodede Base64 mojibaken.