Base64 URL Safe Converter
Base64URL
SGVs...
How it works
Standard Base64 encoding uses the characters A–Z, a–z, 0–9, +, and /, plus = padding. The + and / characters are unsafe in URLs and file names because / is a path separator and + is the URL encoding of a space. URL-safe Base64 (Base64url, defined in RFC 4648 §5) replaces + with - and / with _, and typically omits padding.
**Where Base64url is used** JWT (JSON Web Token): header and payload are Base64url encoded without padding. The three parts are separated by dots: header.payload.signature. URL shorteners and content-addressable storage: file hashes and IDs embedded in URLs must not contain /. OAuth 2.0 PKCE: the code_challenge parameter is the Base64url encoding of SHA-256(code_verifier). Google's Protocol Buffers web encoding. WebSafe data transfer in HTML data attributes.
**Conversion rules** Standard → URL-safe: replace + with -, replace / with _, remove = padding. URL-safe → Standard: replace - with +, replace _ with /, add = padding to make length a multiple of 4 (add 1 or 2 = characters as needed). The padding rule: length mod 4 == 2: add ==; length mod 4 == 3: add =; length mod 4 == 0: no padding needed.
**Decoding safety** When decoding untrusted Base64url-encoded content (e.g., JWT payloads), always validate the signature before trusting the payload. Base64 is encoding, not encryption — the payload is plainly readable to anyone with the encoded string.
Frequently Asked Questions
- Two character replacements + padding removal: replace all + with -, replace all / with _, remove all = padding characters. In JavaScript: btoa(str).replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, ''). In Python: base64.urlsafe_b64encode(data).rstrip(b'=').decode(). Reverse (decode): add padding (calculate needed = characters: (4 - len % 4) % 4), replace - with +, replace _ with /, then decode standard Base64.
- JWT uses Base64url to make the token safe for inclusion in URLs (as a query parameter), HTTP headers, and HTML attributes without URL encoding. Standard Base64's + and / characters are URL-unsafe: + is the URL encoding of a space, and / is interpreted as a path separator. The = padding is omitted for compactness and because the decoder can infer the correct padding from the string length. The three sections of a JWT (header.payload.signature) use dot . as separator, which is also URL-safe.
- Take the middle section (between the first and second dot). Add padding if needed: if length % 4 == 2, add '=='; if % 4 == 3, add '='. Replace - with + and _ with /. Base64-decode to get JSON bytes. Parse the JSON. In JavaScript: JSON.parse(atob(token.split('.')[1].replace(/-/g,'+').replace(/_/g,'/')+'=='.slice(0,((4-token.split('.')[1].length%4)%4)))). Note: this reads the payload but does NOT verify the signature — never trust unverified JWT claims.
- No. Base64 is encoding — it converts binary data to a printable ASCII representation. It is completely reversible with no key. Anyone who sees a Base64 string can decode it instantly. It provides zero confidentiality. Common misconception: 'obfuscating' data with Base64 is not security. API keys, passwords, and sensitive data encoded in Base64 are just as exposed as plaintext — they just look different. Encryption requires a secret key; Base64 has no key.