> base64url | jwt | url-safe <

Base64url is a URL and filename-safe variant of Base64 encoding. It replaces '+' with '-', '/' with '_', and optionally removes padding '=' characters to avoid URL encoding issues.

Regular Base64 uses '+', '/', and '=' characters which have special meanings in URLs. The '+' becomes a space, '/' is a path separator, and '=' is used for parameters, causing parsing issues.

Base64url is widely used in JWTs (JSON Web Tokens), OAuth 2.0 authorization codes, SAML assertions, and any API that needs to pass binary data in URLs or HTTP headers.

No, padding is optional in Base64url. Many implementations omit padding since the length can be calculated. JWTs specifically require no padding for a cleaner URL appearance.

The two variants are defined in RFC 4648:
• Standard Base64 (§4) — uses A-Z, a-z, 0-9, +, /, padded with =. The + and / characters have special meaning in URLs and filenames.
• URL-safe Base64 (§5, also called base64url) — identical except + becomes - and / becomes _. Both variants encode identical data; only the last two alphabet characters differ. Use the table below to convert between them:

A one-line string replacement: b64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '') in JavaScript. The reverse (Base64url → standard) is the same substitutions in the opposite direction, plus re-adding = padding until the length is a multiple of 4. Most libraries provide this out of the box — see the code samples below.

Built-in support varies by platform:
Node.js — Buffer.from(str).toString('base64url') and Buffer.from(b64url, 'base64url').toString() (native since Node 16)
Python — base64.urlsafe_b64encode(b) / base64.urlsafe_b64decode(s)
Java — Base64.getUrlEncoder().withoutPadding().encodeToString(bytes) / Base64.getUrlDecoder().decode(str)
Go — base64.RawURLEncoding.EncodeToString(b) / base64.RawURLEncoding.DecodeString(s) ("Raw" = no padding)
PHP — rtrim(strtr(base64_encode($s), '+/', '-_'), '=') to encode
Browser JS — no native URL-safe helper; run btoa(str) then replace characters manually, or use TextEncoder + Uint8Array helpers

A JSON Web Token is three Base64url-encoded segments separated by dots: <header>.<payload>.<signature>. Each segment is Base64url without padding — RFC 7515 (JWS) explicitly mandates omitting the = characters. This means a JWT is safe to drop into a URL query parameter, an Authorization header, or a cookie without further escaping. If you see a JWT anywhere containing +, /, or =, it was encoded incorrectly and most parsers will reject it.

Pick based on where the string will travel:
• URLs, filenames, HTTP headers, cookies — use Base64url so no further escaping is required
• JSON/XML bodies, email, databases — either works; standard Base64 is the historical default
• JWT, OAuth 2.0, WebAuthn, WebPush, JWE, JWK — Base64url without padding is required by spec
When in doubt, Base64url is the safer modern choice because it is guaranteed not to collide with URL-reserved characters.

Without padding, Base64url is slightly smaller because it drops 0–2 = characters at the end. With padding, the two are identical in size. Both variants produce output approximately 33% larger than the raw binary — that overhead comes from the 6-bit-to-8-bit representation ratio and is unavoidable for any text-safe binary encoding.

Yes, and most modern specifications prefer it that way. The padding (=) exists only so that chunked processing of a Base64 stream can find byte boundaries without knowing the total length. If you are encoding a complete buffer (which is almost always the case for JWTs, OAuth tokens, and URL parameters), the length is implicit and padding adds no information. RFC 4648 §3.2 explicitly allows padding to be omitted, and RFC 7515 requires it omitted for JWS/JWT.

If your decoder is strict and rejects unpadded input, append = characters until the length is a multiple of 4. In JavaScript: str + '==='.slice((str.length + 3) % 4). In Python, urlsafe_b64decode needs padding, so a common pattern is base64.urlsafe_b64decode(s + '=' * (-len(s) % 4)).