Base64 encoder, decoder. URL-safe and binary too.
Paste text or Base64. We auto-detect direction and convert. Toggle URL-safe mode (replaces +// with -/_), drop a file for binary encoding, choose line-wrap. UTF-8 native — never sent to a server.
Paste text or Base64. We auto-detect the direction and convert. Toggle URL-safe mode for JWTs and URL parameters, drop a file for binary encoding, choose line-wrap for MIME / PEM contexts. UTF-8 native, browser-only.
// output appears here
Sources used
- RFC 4648 — Base16, Base32, Base64 encoding standard. §4 standard, §5 URL-safe.
- MDN btoa / atob — browser-native Base64 APIs
- MDN FileReader — used for binary file input
No data is sent to Digital Heroes servers. Conversion is entirely client-side.
Privacy: encoding happens in your browser. Nothing is sent or logged.
Two variants. Different jobs.
Standard Base64 (RFC 4648 §4) uses 64 characters: A-Z a-z 0-9 + /. The plus and slash are not URL-safe — both have special meaning in URLs and many filesystems. Use standard Base64 for: HTTP Basic auth headers, data URIs (data:image/png;base64,…), embedded fonts in CSS, base64-encoded values in YAML / JSON. About 95% of Base64 usage in modern web stacks.
URL-safe Base64 (RFC 4648 §5) substitutes the unsafe characters: + becomes -, / becomes _, and the trailing = padding is usually dropped. Use URL-safe for: JSON Web Tokens (the three dot-separated parts are all URL-safe Base64), OAuth state parameters, signed URLs, filenames that need to round-trip through Base64, anything you'll put in a URL fragment or query parameter.
The padding question. Standard Base64 pads with = to a multiple of 4 characters. URL-safe usage commonly drops the padding because URLs find equals signs awkward. Both are valid; both decode correctly. Our decoder accepts either form (with or without padding) so you can paste whatever you have without thinking about it.
Four jobs this tool covers.
Job 1: Inspect a JWT. JSON Web Tokens are three URL-safe Base64 segments separated by dots — header, payload, signature. Paste any segment with URL-safe mode on, decode it, read the JSON. Useful for debugging auth flows, verifying expiration claims, checking token issuer. The signature segment decodes to binary (the cryptographic hash) and is not human-readable.
Job 2: Embed a small image as a data URI. Drop an image file, toggle 'data:URI prefix,' copy the result. Paste into a CSS background-image, an HTML img src, or a Markdown image — the image embeds inline with no separate HTTP request. Useful for icons under 5KB; above that, a real image file with HTTP/2 push or preload performs better.
Job 3: Decode an unfamiliar Base64 string. Some API or log line returned eyJhbGciOiJIUzI1NiJ9 — paste in auto-detect mode, the tool decodes to {"alg":"HS256"}. Common for inspecting webhook payloads, AWS Cognito tokens, GitHub Actions outputs, or any system using Base64 for transport.
Job 4: Encode binary content for a JSON / YAML field. Configuration files like Kubernetes Secrets, GitHub Actions secrets, or Docker compose files often want binary content (a TLS cert, a private key, a small file) embedded as a Base64 string. Drop the file, copy the encoded string, paste into the YAML. For PEM-format certificates and keys, toggle the wrap-at-76 option to match what tools like OpenSSL emit by default.
Six questions users ask.
What's the difference between standard and URL-safe Base64?
Standard Base64 (RFC 4648 §4) uses 64 characters: A-Z, a-z, 0-9, plus '+' and '/'. The plus and slash break URL parameters and filenames, so URL-safe Base64 (RFC 4648 §5) substitutes them with '-' and '_' respectively, and optionally drops the trailing '=' padding. Use URL-safe when the encoded output goes into a URL, JSON Web Token, OAuth state parameter, or filename. Use standard everywhere else (data URIs, basic auth headers, file embedding).
Why is my decoded UTF-8 garbled?
If the original was encoded as Latin-1 or another non-UTF-8 charset, decoding as UTF-8 will produce mojibake. Modern web encoding is universally UTF-8; legacy systems sometimes used Windows-1252 or Latin-1. We use TextDecoder('utf-8') by default, which is the correct choice for 99% of modern Base64 you'll encounter. If you know the source was a different encoding, you'll need a tool that supports the legacy charset or convert at the source first.
How do I encode a binary file?
Drop the file onto the input panel or click 'choose file.' We read the raw bytes via FileReader.readAsArrayBuffer, then Base64-encode them — same algorithm browsers use to construct data URIs from images. Useful for embedding small images, fonts, or icons inline in HTML / CSS / JSON. The 'data: prefix' toggle wraps the output in a 'data:image/png;base64,…' URI ready to paste into a src attribute.
What's the line-wrap option for?
Some legacy contexts (RFC 2045 MIME headers, PEM-encoded keys, S/MIME) require Base64 wrapped at 76 characters per line. Modern HTTP, JSON, and JWT all use unwrapped (single-line) Base64. Default is unwrapped because that's what 99% of modern usage needs; toggle on for cases where you're writing email-MIME content or PEM blocks.
Is the data I paste sent anywhere?
No. We use the browser's native btoa, atob, TextEncoder, TextDecoder, and FileReader APIs — all run client-side. The page is static HTML; the only network request is the initial page load. Safe for API keys, JWT secrets, encoded credentials, or any sensitive value you don't want uploaded to a third party.
Why does base64 of a 100-byte string take 136 characters?
Base64 encodes every 3 input bytes as 4 output characters — a fixed ~33% size overhead, plus padding. The exact formula is ceil(N/3) × 4 characters for N input bytes, with '=' padding to round up. So 100 bytes → 136 chars (132 data + 4 padding). This is the cost of representing binary data using only printable-ASCII safe characters. For larger payloads, gzip the binary first, then Base64 — the compression usually outweighs the encoding overhead.