Base64 encoder / decoder

Paste text, encode to Base64 or decode it back. Standard or URL-safe alphabet, UTF-8 throughout.

Built for quick API payloads, data URLs, and JWT-adjacent debugging. Conversion stays in this tab.

Client-side only. Text is UTF-8 encoded before Base64. Nothing is uploaded.

Same string, two alphabets

Base64 turns bytes into ASCII. The classic alphabet uses + and /. URL-safe (RFC 4648 base64url) swaps those for - and _ so the value survives query strings. Same input bytes, different characters:

Input (UTF-8)StandardURL-safe (no pad)
Hi?SGk/SGk_
a+bYStiYSti (no +/ here)
subjects?_dcontains +// when those bytes appearuses -/_ instead
Hello, ToolPetalSGVsbG8sIFRvb2xQZXRhbA==SGVsbG8sIFRvb2xQZXRhbA

Tick URL-safe when the consumer expects base64url (JWTs, many OAuth challenges). Leave it off for classic MIME-style Base64.

Encode path, decode traps

Encode: this page runs TextEncoder (UTF-8), then Base64. Emoji and accented characters are fine; legacy Latin-1-only encoders are not what you get here.

Decode: Base64 first, then TextDecoder with fatal: true. If the bytes are not valid UTF-8 text, you get an error instead of silent garbage. Binary blobs belong in a hex or file tool, not in a text box pretending to be UTF-8.

Padding (=): some APIs strip it. Leave Keep / restore = padding on unless you know the peer wants unpadded strings. On decode, missing padding is restored when the length needs it.

What this page will not do

FAQ

Does this Base64 tool upload my text?

No. Encoding and decoding run in JavaScript on this page. ToolPetal has no backend for Base64 conversion.

What is the difference between standard Base64 and URL-safe?

Standard Base64 uses + and / and often ends with = padding. URL-safe (base64url) swaps those for - and _ so the string survives query strings and path segments. Toggle URL-safe on this page when you need that alphabet.

Why does decode fail on some strings?

Common causes: wrong alphabet (standard vs URL-safe), missing or extra = padding, whitespace you meant to keep, or bytes that are not valid UTF-8 when decoded as text. This page reports the error instead of inventing output.

Is Unicode handled correctly?

Yes for text mode. Encode runs TextEncoder (UTF-8) before Base64. Decode runs TextDecoder (UTF-8, fatal) after Base64 so invalid byte sequences surface as errors rather than mojibake.