Base64 & Base64URL encoder and decoder

Convert text, binaries, and tokens between plain UTF-8 and Base64, URL-safe Base64URL, or hexadecimal format. Executes 100% locally with zero external network transmission.

How to encode or decode Base64

Choose Encode to transform plain text into Base64, or Decode to convert Base64 back to readable text.
Select your target format from the Format dropdown:
- Standard Base64 — standard RFC 4648 format using +, /, and = padding.
- URL-safe (Base64URL) — replaces + with - and / with _, omitting padding (standard for JWTs and OAuth 2.0 PKCE).
- Hexadecimal — base-16 binary byte representation (useful for hashes, MACs, and checksums).
Type or paste your data into the input pane. Output is calculated and formatted in real-time.
Use Copy Output or Download to export your result directly.

How Base64 Encoding Works: The Mathematics of 6-Bit Blocks

Computers store and transmit binary data in 8-bit bytes (values from 0 to 255). However, many legacy communication protocols (such as SMTP email, URL query strings, and early HTTP headers) were designed exclusively to transmit 7-bit US-ASCII printable characters. Transmitting raw binary bytes over such channels frequently corrupted data due to control characters or line-break conversions.

Base64 (standardized under RFC 4648) solves this problem by re-encoding arbitrary binary data into a set of 64 universally safe printable characters:

The encoder takes 3 consecutive 8-bit bytes of data (totaling 24 bits: \(3 \times 8 = 24\)).
These 24 bits are partitioned into 4 6-bit groups (\(4 \times 6 = 24\)).
Each 6-bit group represents an integer value between 0 and 63 (\(2^6 = 64\)).
Each integer maps to an ASCII character defined by the standard Base64 index table:
- Values 0–25 map to uppercase letters A–Z.
- Values 26–51 map to lowercase letters a–z.
- Values 52–61 map to digits 0–9.
- Value 62 maps to +.
- Value 63 maps to /.

Because 3 input bytes become 4 output characters, Base64 encoding introduces a predictable 33.3% size overhead (4/3 expansion ratio), plus any trailing padding bytes.

Understanding Base64 Padding Rules (`=`)

What happens when the input data length is not evenly divisible by 3? The RFC 4648 specification defines padding using the equal sign (=):

2 Leftover Bytes (16 bits): Padded with 2 zero bits to form three 6-bit groups. The encoder appends a single = character to make the total output length a multiple of 4 (e.g. any_ becomes 4 characters ending in =).
1 Leftover Byte (8 bits): Padded with 4 zero bits to form two 6-bit groups. The encoder appends two == padding characters (e.g. a becomes 4 characters ending in ==).
No Leftover Bytes: Output length is an exact multiple of 4; no padding is required.

Standard Base64 vs Base64URL: Avoiding Web & API Bugs

In standard Base64, the 62nd and 63rd characters are + and /, with = used for padding. While safe in email bodies and MIME headers, these three characters cause severe issues in web technologies:

URL Query Strings: Web browsers interpret the + symbol as an encoded space character, corrupting the payload unless manually escaped to %2B.
URL Path Segments: The forward slash / divides URL directory paths, causing web servers to misroute requests.
Query Delimiters: The = sign delimits key-value parameter pairs.

To resolve this, RFC 4648 Section 5 defines Base64URL:

Character Function	Standard Base64	URL-Safe Base64URL
Value 62	`+` (plus)	`-` (hyphen / minus)
Value 63	`/` (forward slash)	`_` (underscore)
Padding	`=` or `==` (mandatory)	Omitted entirely (unpadded)
Primary Systems	MIME email, data URIs, Basic Auth	JWT tokens, OAuth 2.0 PKCE, WebAuthn

Handling Unicode & Emojis Without Browser Crashes

A notorious pitfall in JavaScript is the legacy window.btoa() and window.atob() functions. If you attempt to encode modern Unicode strings containing accents or emojis (such as "DevSandbox ⚡"), the browser throws an immediate runtime exception:

Uncaught DOMException: Failed to execute 'btoa' on 'Window': The string to be encoded contains characters outside of the Latin1 range.

DevSandbox avoids this limitation by utilizing the modern browser TextEncoder and TextDecoder streaming APIs. Characters are properly converted into raw UTF-8 byte streams before encoding, guaranteeing seamless conversion for all world languages, technical symbols, and emojis.

Developer Use Cases

HTTP Basic Authentication: Generating authorization headers via Authorization: Basic base64(username:password).
Inline Data URIs: Embedding SVGs, fonts, and raster images directly into CSS stylesheets or HTML documents via data:image/svg+xml;base64,....
Cryptographic Hashes & Secrets: Converting raw byte buffers into hexadecimal or Base64 strings for HMAC tokens, SSH fingerprints, and public keys.

100% Client-Side Privacy Guarantee

Pasting API tokens, passwords, or binary signatures into traditional online encoders exposes your credentials to third-party server logs. DevSandbox processes all Base64 and Hex transformations strictly in your browser's local memory. The site's Content Security Policy blocks all external network exfiltration, ensuring complete confidentiality.

Frequently asked questions

What is the difference between Base64 and Base64URL?

Standard Base64 uses + and / characters with = padding. Base64URL replaces + with - and / with _, omitting padding so that the encoded string is safe for use in URL query parameters, path segments, and JSON Web Tokens.

Does this encoder support UTF-8 characters and emojis?

Yes. DevSandbox uses modern TextEncoder and TextDecoder streams rather than legacy Latin-1 restricted functions, ensuring full multi-byte Unicode and emoji compatibility.

Can I encode binary files?

Yes. You can paste or drag-and-drop text and data files directly into the editor to encode them into Base64 or Hex.

Why does Base64 output end with equals signs?

Base64 encodes data in 24-bit (3-byte) blocks. When the input length is not an exact multiple of 3, the encoder appends one or two = characters as padding to complete the 4-character output block.

How much size overhead does Base64 encoding add?

Base64 encoding increases data size by approximately 33.3% because every 3 bytes (24 bits) of raw data are represented using 4 6-bit ASCII characters.