Live100% Client-Side

Base64URL Encoder & Decoder

Encode and decode RFC 4648 §5 URL-safe Base64 strings for JWTs, OAuth tokens, and URL parameters.

Encode and decode URL-safe Base64URL strings conforming to RFC 4648 §5. Uses minus and underscore characters without trailing padding for JWT and web tokens.

Workbench

Use Base64URL Encoder & Decoder

Ctrl/⌘ + Enter to process

Input

Plain text or JSON to encode

Output

Base64URL output

Ready. Enter text or load the sample, then encode.

What it does

Built for the task, not the page view

Default RFC 4648 §5 URL-safe alphabet: 62 is "-" and 63 is "_"
Default unpadded mode (strips trailing "=") with optional padding toggle
Automatic modulo 4 padding reconstruction for decoding unpadded tokens
Full UTF-8 multi-byte character and emoji support via native TextEncoder/Decoder
Bi-directional Encode and Decode modes with instant input/output swapping
Diagnostic error messages with exact invalid character, offset, and line markers
One-click clipboard copy and text file download

Inputs & outputs

Accepts

UTF-8 TextBase64URL StringJWT Token Part

Produces

Base64URLUTF-8 Text

Reference

Use it correctly

Base64URL is encoding, NOT encryption

Base64URL is a serialization and representation scheme, never encryption. It provides zero confidentiality, secrecy, or cryptographic security. Any client, server, or intermediary can decode Base64URL back to plaintext in milliseconds without a secret key or password. Never rely on Base64URL to protect passwords, API credentials, or confidential personal data.

RFC 4648 §5 URL-Safe Alphabet (- and _)

Standard Base64 (RFC 4648 §4) uses "+" and "/" for index 62 and 63. In web addresses, "+" is interpreted as a space in query strings (application/x-www-form-urlencoded) and "/" serves as a path delimiter. Base64URL substitutes "-" (minus/hyphen) for "+" and "_" (underscore) for "/", making encoded strings safe for URL paths, query parameters, HTTP headers, and filenames without percent-encoding.

Padding Rules & Modulo 4 Reconstruction

Standard Base64 appends trailing "=" characters to reach a multiple of 4 characters. In web tokens (such as JWTs) and URLs, trailing "=" characters are stripped by default because "=" is reserved for query parameters (key=value). When decoding unpadded Base64URL, our engine automatically computes (4 - (len % 4)) % 4 to reconstruct necessary padding before byte conversion.

JWT & OAuth Web Token Architecture

JSON Web Tokens (RFC 7519) mandate unpadded Base64URL encoding for their header, payload, and cryptographic signature components (separated by periods). OAuth 2.0 PKCE (RFC 7636) code challenges also require unpadded Base64URL SHA-256 hashes. This tool provides instant encoding and decoding of individual token segments.

Unicode & UTF-8 Multi-Byte Character Support

Legacy JavaScript window.btoa() throws an error when processing characters outside the Latin1 range (code points > 255). This engine uses the browser native TextEncoder and TextDecoder to serialize Unicode (including international scripts, accents, and emojis) into UTF-8 byte streams before Base64URL conversion, ensuring complete character integrity.

Local In-Browser Processing Guarantee

All Base64URL encoding and decoding operations execute strictly within your local browser tab using Web APIs and typed arrays. Your authentication tokens, API payloads, and private text strings are never transmitted to an EveryTools transformation API or logged to external servers.

RFC 4648 §5 URL-Safe Base64 Technical Guide

Base64URL (defined in RFC 4648 §5) is a specialized variant of Base64 engineered for transport over URL paths, query parameters, and web tokens without requiring percent-encoding. The table below illustrates how Base64URL differs from standard Base64.

Property	Standard Base64 (RFC 4648 §4)	Base64URL (RFC 4648 §5)	Impact on Web & API Usage
Character 62	`+` (Plus)	`-` (Minus / Hyphen)	`+` becomes space in query strings; `-` is URL-safe.
Character 63	`/` (Forward slash)	`_` (Underscore)	`/` splits URL paths; `_` is safe in all URI segments.
Padding	`=` (Required for 4-char alignment)	Omitted by default (Unpadded)	`=` conflicts with query parameters (`key=val`) and requires `%3D` escaping.
Primary Use Cases	MIME emails, data URIs, XML payloads	JWT tokens, OAuth 2.0 PKCE, URL query IDs	Guarantees zero URL encoding overhead and compact token length.

Padding Reconstruction & Modulo 4 Mechanics

Because Base64URL strips trailing = padding characters to prevent URL query collisions, decoders must calculate the missing padding using modulo arithmetic prior to byte decoding:

Length % 4 === 0

The Base64URL string is already evenly aligned. No padding is needed before decoding.

// Example: 8 characters
"eyJzdWIi" -> Valid without padding

Length % 4 === 2

Two characters remain in the final 4-character block. Exactly two == padding characters must be appended.

// Example: 6 characters
"SGVsbG8" -> append "==" -> "SGVsbG8=="

Length % 4 === 3

Three characters remain in the final 4-character block. Exactly one = padding character must be appended.

// Example: 7 characters
"SGVsbG93" -> append "=" -> "SGVsbG93="

Length % 4 === 1

Illegal Base64 state. A single 6-bit chunk cannot represent an 8-bit byte. The engine flags this as a malformed length error.

// Example: 5 characters
"SGVsb" -> Error: standalone character

Explore EveryTools