PEM Formatter
Normalize PEM boundaries and Base64 wrapping without guessing the encoded object type.
Formatted PEM
Formatted PEM output will appear here.
Private-key text deserves private-key handling
Formatting runs on the pasted string in the current browser tab; no formatter endpoint is needed. That does not protect a key from browser extensions, clipboard history, screen capture, shared-device access, or backups. Prefer a non-production sample when the real private key is not required for the task.
PEM is a boundary plus Base64, not a certificate format by itself
A PEM-style block is a textual envelope around Base64-encoded bytes. The label says what those bytes are supposed to represent: CERTIFICATE, PUBLIC KEY, PRIVATE KEY, CERTIFICATE REQUEST, and several other labels are used by PKIX and related formats.
Rewrapping Base64 cannot turn one object type into another. A block labelled PUBLIC KEY is expected to contain a public-key structure, but formatting alone does not ASN.1-decode the bytes to prove that the label is truthful.
Why the output returns to 64 characters per Base64 line
RFC 7468 requires generators for these textual encodings to wrap the Base64 body at exactly 64 characters per line except for the final line. Parsers in the wild are often more tolerant, which is why copied keys and certificates may arrive with unusual wrapping or extra whitespace.
The formatter removes whitespace from the body, decodes the Base64, checks canonical pad bits, restores required padding when it was omitted, and re-encodes the same bytes before applying 64-character wrapping. BEGIN and END labels are preserved exactly when they match.
Reference: RFC 7468 — Textual Encodings of PKIX, PKCS, and CMS Structures
Some damage can be repaired; some should stop the conversion
Safe normalization
- CRLF, CR, and LF line endings can be read.
- Whitespace inside a Base64 body can be removed.
- Missing final Base64 padding can be reconstructed from length.
- Several complete PEM blocks can be emitted in order.
Stop and investigate
- BEGIN and END labels do not match.
- A boundary is incomplete, nested, or malformed.
- The Base64 alphabet, length, padding, or pad bits are invalid.
- Legacy header lines appear inside the encapsulated body.
Text outside a block is different from text inside it
RFC 7468 allows parsers to encounter text before or after an encapsulated object. Here, non-empty outside text is omitted from the formatted PEM and surfaced as a warning so a copied comment, shell prompt, or certificate-chain note is not silently folded into the Base64 body.
Legacy PEM encryption headers such as Proc-Type: orDEK-Info: are a different syntax. They are rejected rather than stripped because removing those lines can destroy the information needed to interpret an encrypted legacy key.
Formatting cannot answer certificate or key-validity questions
- Certificate trust, expiry, hostname matching, revocation, and extensions are not evaluated.
- A private key is not compared with a certificate or public key.
- Encrypted private keys are not decrypted and passphrases are never requested.
- The ASN.1 object inside the Base64 bytes is not parsed to confirm it matches the boundary label.
- OpenSSH private-key files and OpenPGP ASCII armor are different textual formats and are outside the PEM normalization covered here.