Base64 Encode / Decode
Encode text to Base64 and decode it back, with URL-safe variant support and correct UTF-8 handling.
Inputs
Use URL-safe when embedding Base64 in a URL or JWT.
Output
SGVsbG8sIFdvcmxkIQ==
Encoded or decoded result.
Input Length (bytes / chars)
13
Output Length (bytes / chars)
20
Base64 Size Overhead (%)
54
Base64 adds ~33% to the original size (4 output chars per 3 input bytes).
Step by step
Encode input to UTF-8 bytes
"Hello, World!"
= 13 bytes
Encode each 3-byte group as 4 Base64 characters
Alphabet: Standard (RFC 4648 §4)
Result
= SGVsbG8sIFdvcmxkIQ==
How it works
Base64 encodes arbitrary binary data as printable ASCII characters, making it safe to embed in text protocols like JSON, HTML attributes, email (MIME) and HTTP headers. It maps every 3 bytes of input to 4 characters from a 64-character alphabet, resulting in a ≈33% size increase. Standard Base64 (RFC 4648 §4) uses +, / and = padding; URL-safe Base64 (§5) replaces + with -, / with _, and drops padding, making it safe to embed in URLs and JWTs without percent-encoding. This calculator always encodes text as UTF-8 bytes first, which is the only correct way to handle non-ASCII characters like accented letters and emoji.
Formulas
Base64 output length
Output length = ⌈(4/3) × input_bytes⌉ (padded to nearest multiple of 4)
- L_in
- Input length in bytes (UTF-8 encoded)
- L_out
- Output length in Base64 characters (including padding)
Size overhead
Every 3 bytes of input become 4 Base64 characters — a 33% size increase.
Frequently Asked Questions
Why can't I just use btoa() for Unicode strings?
btoa() is a legacy function that only accepts characters in the Latin-1 range (U+0000–U+00FF). Passing a string containing emoji, Chinese characters or any code point above U+00FF causes it to throw or produce wrong output. The correct approach is to first encode the string to UTF-8 bytes (via TextEncoder), then Base64-encode those bytes.
When should I use URL-safe Base64?
Whenever the Base64 output will appear in a URL query parameter, a URL path segment, or a JWT. Standard Base64 uses + and /, which are special characters in URLs and must be percent-encoded. URL-safe Base64 replaces them with - and _ (neither is special in a URL), so no additional encoding is needed.
Can Base64 detect corruption or tampering?
No — it has no checksums or error detection. If a Base64 string has been altered, the decoder will either produce garbage output or throw a 'malformed input' error. For integrity protection, use a hash (SHA-256) or MAC in addition to Base64.
Is Base64 a form of encryption?
No. Base64 is an encoding, not an encryption. It is trivially reversible and provides no confidentiality whatsoever. Anyone who can see the Base64 string can decode it instantly. For confidentiality, encrypt the data with AES or similar before (optionally) Base64-encoding it.