Base64URL Encoder — URL-Safe Base64

Introduction

Standard Base64 uses + and / — fine in JSON, problematic in URL query strings and filename paths without extra encoding. JWTs and many OAuth flows mandate Base64URL: replace + with -, / with _, and strip = padding. Developers manually regex-transform standard Base64 or misconfigure libraries. A paste encoder clarifies the exact transformation pipeline.

Certoflow's Base64URL Encoder UTF-8 encodes input via encodeURIComponent and btoa, then applies URL-safe substitutions and removes trailing padding equals signs. Live output as you type. Local processing — suitable for JWT header/payload experiments, not for signing with production private keys in browser unless you accept key exposure risks. Pair with Base64 Encode for standard alphabet, JWT Decoder for inspecting assembled tokens, and URL Encoder when embedding encoded values in full URLs.

What this tool does

Step	Operation
UTF-8 encode	encodeURIComponent + unescape + btoa
URL-safe	+ → -, / → _
Padding	Remove trailing = characters
Output	Base64URL string without padding

Empty input yields no output panel. No decode mode in this tool.

How it works

const b64 = btoa(unescape(encodeURIComponent(input)));
return b64.replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");

This matches common JavaScript JWT library encoding for JSON segments. Binary files are not uploaded — text input only. For image bytes, use Image to Base64 then manually URL-safe transform if needed.

Real-world examples

JWT header/payload inspection

Encode {"alg":"HS256","typ":"JWT"} minified JSON segments before manual HMAC with HMAC SHA256 Generator for educational token assembly — compare with JWT Decoder round-trip.

OAuth state parameter

Generate URL-safe encoded state blobs for authorization redirect testing with Query String Builder assembling full redirect URLs.

Deep link query values

Encode Unicode campaign names safely in mobile deep links without + misinterpreted as space in query parsing.

Contrasting standard Base64

Same input through Base64 Encode shows +// and padding — side-by-side teaches URL-safe differences.

API documentation examples

Document expected Base64URL encoding of client IDs for partner integration guides.

Common mistakes

Using standard Base64 in JWT signature segment. Libraries expect Base64URL for all three JWT parts — mismatch breaks verification.

Re-adding padding manually. Many decoders accept unpadded URL-safe strings — do not pad unless target API requires it.

Encoding binary files via text paste. Text encoder not for arbitrary binary — use appropriate binary-to-base64 tools.

Assuming decode symmetry in this UI. Encode only — decode via Base64 Decode with manual URL-safe reverse transform if needed.

Signing JWTs in browser with production secrets. Encoding is fine; HMAC with live keys in DevTools exposes secrets — use test keys from API Key Generator.

Unicode normalization issues. Different NFC/NFD Unicode forms encode differently — normalize before encode if comparing cross-platform.

Use cases

Frontend developers debugging OAuth and JWT libraries.

Mobile developers constructing URL-safe deep link parameters.

API integrators verifying encoding matches spec examples.

Students learning Base64 versus Base64URL differences.

Technical writers generating correct encoded samples.

QA engineers building expected encoding fixtures.

FAQ

Padding removed?

Yes. Trailing = stripped per Base64URL convention.

Character substitutions?

+ becomes -, / becomes _.

Decode support?

Not in this tool — use Base64 Decode with URL-safe pre-processing.

UTF-8 support?

Yes, via encodeURIComponent pipeline.

Difference from Base64 Encode?

Standard Base64 retains +, /, and padding.

JWT related?

Yes — JWT segments use Base64URL. Inspect tokens with JWT Decoder.

Live encoding?

Yes, when input non-empty.

Offline?

Yes.

Binary input?

Text only — not file upload.

HMAC signing?

Encode payload here; sign with HMAC SHA256 Generator separately for learning exercises.

RFC 4648 URL-safe alphabet

Base64URL is defined in RFC 4648 alongside standard Base64. The URL and filename safe variant removes characters that require percent-encoding in URIs or cause issues on case-insensitive filesystems. JWT specification (RFC 7519) mandates Base64URL encoding without padding for all three dot-separated segments. Libraries typically handle encoding internally — manual encoding helps when debugging signature mismatches: verify each segment encodes identically before blaming the HMAC key. Padding omission is intentional; decoders reconstruct missing = based on length mod 4. If a partner API rejects unpadded strings, append padding manually and test. Contrast encoded output with Base64 Encode on the same string to see exactly which characters changed — teaching moments for bootcamp students learning why copying standard Base64 into URL query parameters broke their OAuth redirect tests until they applied - and _ substitution and stripped equals signs per JWT and OpenID Connect conventions used alongside JWT Decoder inspection of header and payload claims.