About this tool
Base64 Encode/Decode is a free text and code tool that runs entirely in your web browser. Type in the plain-text pane and the Base64 pane fills in as you type; paste Base64 the other way and decode it back, with UTF-8 handled correctly so emoji and accented characters round-trip intact. Switch to the File tab to drop any file up to 25 MB and get its Base64 plus a ready-to-paste data: URI, or paste Base64 and download the original file it encodes. Because everything happens locally on your device, your data is never uploaded, there is no sign-up, and it keeps working offline. Like every HeroTool by Digital Heroes, it is 100% free with no limits.
Standard vs URL-safe Base64: 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, and Base64-encoded values in YAML or JSON. That covers 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, and anything you will put in a URL fragment or query parameter. The URL-safe checkbox above switches the encoder's output alphabet.
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. The decoder on this page 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 a segment into the Base64 pane and click Decode; the decoder accepts URL-safe characters and missing padding automatically, so the JSON appears in the plain-text pane. Useful for debugging auth flows, verifying expiration claims, or checking the token issuer. The signature segment decodes to binary (the cryptographic hash), so you will see a hex preview instead of text. For the full three-part breakdown, use our JWT Decoder.
Job 2: Embed a small image as a data URI. Switch to the File tab, drop an image, and copy straight from the data: URI pane; the tool also shows an inline preview of the image it encoded. Paste the URI into a CSS background-image, an HTML img src, or a Markdown image and it loads inline with no separate HTTP request. Best for icons under 5KB; above that, a real image file with preload performs better.
Job 3: Decode an unfamiliar Base64 string. Some API or log line returned eyJhbGciOiJIUzI1NiJ9. Paste it into the Base64 pane, click Decode, and read {"alg":"HS256"} in the plain-text pane. Common for inspecting webhook payloads, AWS Cognito tokens, GitHub Actions outputs, or any system using Base64 for transport. If the bytes turn out to be a file rather than text, the File tab's Base64 → File pane reconstructs and downloads it.
Job 4: Encode binary content for a JSON or 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 in the File tab, copy the encoded string, paste it into the YAML. For PEM-format certificates and keys, toggle 'Wrap at 76' to match what tools like OpenSSL emit by default.
Frequently asked questions
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 produces mojibake. Modern web encoding is universally UTF-8; legacy systems sometimes used Windows-1252 or Latin-1. This tool decodes with TextDecoder('utf-8') in strict mode, the correct choice for 99% of modern Base64, and shows a hex preview instead of garbled characters when the bytes are not valid UTF-8. If you know the source used a legacy charset, convert at the source or use a tool that supports that encoding.
How do I encode a binary file?
Switch to the File tab and drop the file onto the dropzone, or click it to browse (any type, up to 25 MB). The tool reads the raw bytes via FileReader.readAsArrayBuffer and Base64-encodes them, the same algorithm browsers use to construct data URIs from images. You get the Base64 string and a data: URI built from the file's MIME type, each with its own copy button, plus a 'Download .txt of Base64' option for large outputs.
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 'Wrap at 76' when you're writing email-MIME content or PEM blocks. The wrap applies to text-mode output, the file-mode Base64 pane, and the downloaded .txt alike.
Is the data I paste sent anywhere?
No. The tool uses the browser's native btoa, atob, TextEncoder, TextDecoder, and FileReader APIs, all running client-side on this static page. No network request carries your content. 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.