Gera Tools

Base64 Encoder/Decoder with Binary Safety

Encode or decode Base64 and Base64url strings with binary-safe handling

Encode UTF-8 text or hex bytes to standard Base64 or URL-safe Base64url, and decode either variant back to text. Binary-safe via TextEncoder, detects non-UTF-8 output, and recognises JWT, PEM, and data-URI payloads. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is the difference between Base64 and Base64url?

Standard Base64 uses the characters plus and slash and pads with the equals sign, which can break inside URLs and filenames. Base64url replaces plus with dash and slash with underscore and omits padding, so the result is safe to drop into a URL or JWT segment.

Embed this tool

Drop this free tool into your own site or blog. It runs entirely in your visitor's browser — nothing is sent to us.

<iframe src="https://geratools.com/embed/base64-encoder-decoder" width="100%" height="600" style="border:1px solid #e5e7eb;border-radius:8px" title="Base64 Encoder/Decoder with Binary Safety — GeraTools" loading="lazy"></iframe>

Base64 turns arbitrary bytes into a text string using 64 printable characters, which lets binary data travel safely through systems that only handle text — email, JSON, data URIs, and JWTs. This tool encodes UTF-8 text or hex bytes into Base64 (or URL-safe Base64url) and decodes either variant back, all in your browser.

How it works

Base64 packs every 3 input bytes (24 bits) into 4 output characters (6 bits each):

  1. Encoding text first converts the string to UTF-8 bytes with TextEncoder, so multi-byte characters such as emoji are preserved.
  2. Each group of 3 bytes maps to 4 characters from the alphabet A-Z a-z 0-9 + /; leftover bytes are padded with =.
  3. Base64url then rewrites + to -, / to _, and strips the = padding so the value is safe inside URLs.
  4. Decoding reverses the process, normalising url-safe characters and restoring padding before rebuilding the bytes, then attempting a strict UTF-8 decode.

If a decode produces bytes that are not valid UTF-8, the tool shows hex rather than mojibake.

Why btoa fails on non-ASCII text

The browser’s built-in btoa() function only accepts strings where every character is in the Latin-1 range (code points 0–255). Pass it an emoji or a Chinese character and it throws a InvalidCharacterError. This tool avoids the problem by routing all text through TextEncoder first, which converts the JavaScript string to its UTF-8 byte representation, and then Base64-encodes those bytes. The result is a standard Base64 encoding of the UTF-8 form — the format that most modern APIs and libraries expect.

Worked examples

Encoding the text Hi gives SGk=. Encoding the hex bytes 48 69 (ASCII for “Hi”) gives the same SGk= — handy for verifying protocol payloads where you know the raw bytes.

Encoding the emoji 😀 gives 8J+YgA== (the Base64 of its 4-byte UTF-8 representation F0 9F 98 80). Decoding 8J+YgA== returns 😀.

Common formats you will encounter

JWT (JSON Web Token): three Base64url-encoded segments joined by dots: <header>.<payload>.<signature>. The header and payload are JSON; the signature is raw bytes. Paste any one segment into the decoder to read it — the tool recognises the multi-segment dot pattern and tells you to decode each part separately.

PEM certificate: a block starting with -----BEGIN CERTIFICATE----- and ending with -----END CERTIFICATE----- with 64-character-wrapped standard Base64 between the headers. Strip the headers and paste the body to inspect the DER-encoded certificate as hex.

data URI: data:image/png;base64,<payload> uses standard Base64 for the binary content. Strip the prefix to the comma, then decode the rest to see the raw file bytes.

When you paste a value shaped like xxxxx.yyyyy.zzzzz, the tool recognises a JWT and reminds you to decode the header and payload segments individually. PEM blocks and data: URIs are flagged too, so you know where the actual Base64 body lives.