Encode text to Base64 and decode it back, with URL-safe variant support.
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.
Base64 output length
Output length = ⌈(4/3) × input_bytes⌉ (padded to nearest multiple of 4)
Size overhead
Every 3 bytes of input become 4 Base64 characters — a 33% size increase.
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.
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.
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.
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.