Choose the right Base64 standard.

A correct conversion depends on the receiving protocol. Choose a use case in the converter; its rules and reference are shown before you run it.

URL-safe does not automatically mean unpadded

The alphabet and padding policy are separate decisions. RFC 4648 uses padding unless a referring specification permits its omission. JWS explicitly omits it. Our URL-safe preset is padded; JWT segment is unpadded. Custom lets you accept either form.

Raw bytes (hex):  fb ff
Standard:        +/8=
URL-safe:        -_8=
JWT segment:     -_8

Strict validation, visible compatibility

Standard and URL-safe presets reject whitespace, mixed alphabets, missing or misplaced padding, invalid lengths and nonzero unused trailing bits. The last check enforces a canonical byte representation; RFC 4648 permits decoders to reject nonzero pad bits.

Changing an advanced rule selects Custom, so relaxed settings never appear under a strict preset name. The result panel reports accepted whitespace or omitted padding. It validates encoding syntax, not whether the decoded content is safe, authentic or meaningful.

MIME: line breaks and ignored characters

MIME encoding produces lines of at most 76 characters, separated by CRLF. Our converter preserves the input bytes; it does not normalize the original text’s newlines or create a full email message.

The MIME decoder follows the specification’s rule of ignoring non-alphabet characters. It reports their count, including line breaks, and highlights input that differs from canonical output. It still rejects invalid padding and nonzero pad bits. Use Standard when you want unexpected characters rejected instead. Browsers normalize textarea line breaks to LF; open a local encoded file to inspect its original CRLF bytes. Copy and Save file preserve the chosen output line endings, even though the preview looks the same.

PEM is an envelope, not a certificate generator

Open an existing binary certificate or key, select its correct label, and encode it into one BEGIN/END envelope. Generated body lines are 64 characters except the final line. Choose LF or CRLF in advanced settings. Labels include CERTIFICATE, PUBLIC KEY, PRIVATE KEY, ENCRYPTED PRIVATE KEY, CERTIFICATE REQUEST, X509 CRL, EC PRIVATE KEY and RSA PRIVATE KEY. Their internal formats differ; the label must describe the bytes you already have.

Decoding reads the input label and requires matching boundaries. It accepts LF, CRLF or CR, and reports noncanonical payload wrapping or whitespace. Surrounding prose, multiple blocks, legacy PEM encryption headers and invalid Base64 are rejected. Process a certificate bundle one block at a time.

This tool does not validate ASN.1, DER, certificate chains, encryption, signatures or key material. A successful envelope check does not establish that the contents are a valid certificate or key. Labeling ordinary text CERTIFICATE does not make it one.

A JWT segment is not a complete JWT

Paste one segment without dots or padding. Decoding does not verify its signature or validate expiry, issuer, audience or other claims. Encoding arbitrary bytes produces a Base64URL segment, not a signed token.

Text encoding is a separate step

Text → UTF-8 bytes → Base64. Files use their exact original bytes. GBK, UTF-16 and other character encodings are not Base64 variants; decode to a file if the original text is not UTF-8.

Read the specifications

• RFC 4648 §§3–5: padding, alphabets and canonical bits
• RFC 7515 §2: JWS Base64URL
• RFC 2045 §6.8: MIME Base64
• RFC 7468 §2: textual envelopes

Open the converter →