Base64 Encoder
Type text, get base64 — instantly. Optional URL-safe variant for embedding in JWTs or query strings. Runs entirely on this page so secrets and tokens never leave your device.
Why encode to Base64?
- Embedding a binary credential or signing key into a JSON or YAML config that only accepts text.
- Generating Authorization: Basic headers (`Basic ` + base64 of `user:pass`) for cURL or Postman.
- Producing the data: URLs that inline a small SVG, font, or image directly into HTML or CSS.
- Encoding a request body for a webhook payload that goes through a transport intolerant of binary.
- Building the URL-safe segments of a JWT (the header and payload halves are base64url, padding-free).
- Wrapping config-file blobs in environment variables — many CI systems mangle multi-line strings.
How it works
Your text is UTF-8 encoded into bytes, then bytes are run through the browser's built-in btoa() to produce standard base64 (with the +, /, and = characters). Toggle URL-safe and we substitute - for +, _ for /, and strip the trailing = padding — the variant required by JWTs and most URL-embedded contexts. Everything stays on this page; there's no fetch, no server, no logging.
Frequently asked questions
What's the difference between standard and URL-safe Base64?
Standard base64 uses +, /, and = (padding). Those three characters have meaning in URLs and JSON, so URL-safe base64 swaps + → -, / → _, and drops the = padding. JWTs use URL-safe; HTTP Basic Auth uses standard. When in doubt, the receiver's docs will say.
Does it handle non-ASCII characters?
Yes. The text is UTF-8 encoded before base64ing, so emoji, accented letters, and non-Latin scripts encode correctly. Decoding back through any standards-compliant base64 decoder reverses the process.
Is my text logged or uploaded?
No. Encoding runs as pure JavaScript on this page — no fetch, no XHR, no analytics on input. Safe to paste tokens, API keys, or signing keys.
Can I encode binary files?
Not from this tool — the input is a text field. To encode a file, drop it into a hash tool or use a base64 file-encode workflow. Adding file-input encoding is on the list.
Why is my encoded output different from another tool?
Almost always either UTF-8 vs Latin-1 source encoding, URL-safe vs standard variant, or stripped vs preserved padding. Every standards-compliant decoder will round-trip back to identical bytes despite cosmetic differences.
About this tool
Base64 is the polyfill the internet uses any time arbitrary bytes need to ride through a text-only channel. The mechanic is simple: every three bytes of input become four ASCII characters of output, drawn from a 64-character alphabet (A–Z, a–z, 0–9, plus two more). The trade is bigger payloads (every base64 string is ~33% longer than the bytes it encodes) for guaranteed safe transit. URL-safe base64 (RFC 4648 §5) adjusts the alphabet to drop characters that mean something in URLs, which is why JWTs, OAuth tokens, and most modern signed-token formats use it.