URL Safe Base64 Converter

Convert text or Base64 bytes with RFC 4648's URL-safe alphabet and explicit padding rules.

Input

Text is preserved exactly. Encoded values may have outer whitespace trimmed when that option is enabled.

Conversion settings

Action

Padding

Text encoding

Output layout

Alphabet change

+ becomes -

/ becomes _

= padding is protocol-dependent

Validation and display

Output

Converted Base64URL output will appear here.

Conversion runs in your browser. Yoryantra does not send the pasted value to a conversion API. Base64URL is reversible encoding, so decoded credentials or token material should still be treated as sensitive.

Base64URL changes the transport alphabet, not the bytes

RFC 4648 Base64URL carries the same six-bit values as standard Base64. The two alphabet positions that normally use + and / become - and _, which avoids characters that are awkward in URLs and filenames. Converting a valid Base64 value to Base64URL should therefore preserve the decoded bytes exactly.

Text mode first turns characters into bytes. UTF-8 is the normal choice for modern text. Latin-1 mode is intentionally narrower: every input character must fit in one byte from 0 to 255.

Padding depends on the surrounding protocol

RFC 4648 defines = padding, but specifications that already know the byte length can omit it. A Base64URL value with two data symbols needs two padding characters in canonical padded form; three data symbols need one. A data length that leaves one symbol modulo four cannot represent a valid Base64 quantum.

Do not add or remove padding merely because a value appears inside a token. JWT/JWS profiles commonly omit padding, while another protocol may require the RFC 4648 padded form. Follow the specification that owns the field.

Canonical pad bits prevent multiple spellings of the same bytes

The unused bits in the last Base64 symbol must be zero. A decoder that ignores those bits can accept several different strings for the same byte sequence. Validation here decodes the bytes, re-encodes them canonically, and rejects a value whose meaningful symbols do not round-trip to the same representation.

Text decode

UTF-8 decode is strict. Invalid byte sequences are reported instead of being replaced with U+FFFD, because replacement characters can hide byte corruption.

Binary payloads

Signatures, encrypted blocks, random identifiers, and compressed data may be perfectly valid Base64URL without being text. Convert alphabet/padding without assuming those bytes are UTF-8.

JWT-shaped data is still untrusted data

JOSE formats use Base64URL for compact segments, which makes headers and payloads easy to decode. Readability is not authenticity: signature or authentication-tag verification, algorithm constraints, issuer/audience checks, and time claims happen at a different layer.

Reference for alphabet, padding, and canonical encoding

RFC 4648 defines standard Base64, the URL and filename safe alphabet, treatment of non-alphabet characters, padding, and zero pad-bit requirements. A format that embeds Base64URL can impose additional rules.