PEM Certificate Encoder Decoder
Normalize RFC 7468-style PEM blocks without collapsing bundles, extract canonical Base64 per block, or wrap raw Base64 using deliberate labels and 64-character generator lines.
Normalized PEM, per-block Base64, boundary diagnostics and decoded byte sizes will appear here.
PEM Is a Textual Container Around Binary Structures
The familiar BEGIN/END lines and Base64 body make binary PKIX, PKCS and CMS structures convenient to store in text files. The label tells software what kind of inner object it should expect.
Rewrapping the Base64 changes the text representation, not the certificate, key or CSR bytes. Changing only the label changes even less: it does not convert a PKCS #8 private key into a certificate or a CSR into a public key.
A Certificate Bundle Is Several PEM Blocks, Not One Bigger Certificate
Certificate-chain files commonly concatenate a leaf certificate and intermediate certificates. Each object keeps its own BEGIN CERTIFICATE, Base64 body and END CERTIFICATE boundary.
The older normalization pattern of joining all Base64 bodies and wrapping them once destroys those object boundaries. This version normalizes every block independently and preserves the original block order.
RFC 7468 Generators Use 64-Character Base64 Lines
Parsers are deliberately tolerant of several newline conventions and can accept other line sizes, but RFC 7468 gives generators a concrete output rule: Base64 lines are 64 characters except for the final line that carries the remainder.
Normalized output therefore uses 64 rather than offering arbitrary “pretty” widths. You can choose LF or CRLF because both newline conventions occur in real environments.
BEGIN and END Labels Are Case-Sensitive and Should Match
RFC 7468 generator labels are uppercase and the END label must match the corresponding BEGIN label. Parsers in the wild can be more tolerant, which is why a mismatched file may open in one program and fail in another.
Normalization refuses to silently “fix” a mismatched boundary because choosing which label is correct requires knowing what the inner bytes actually represent.
Historical Labels Can Be Parseable but Poor Generator Output
RFC 7468 standardizes CERTIFICATE for certificates, X509 CRL for CRLs and CERTIFICATE REQUEST for PKCS #10 requests. It also documents historical labels that deployed parsers may encounter.
A diagnostic parser can recognize historical files while a standards-oriented generator should emit the standardized label. This tool reports that distinction instead of equating every old label.
Private-Key PEM Is Secret Material Even When the Formatting Operation Is Local
Certificates and public keys are designed for distribution. Private keys are not. Local browser processing avoids intentionally sending the key to a formatting API, but clipboard history, screenshots, browser extensions, local logs and screen sharing remain real exposure paths.
Prefer test keys when learning or checking formatting. If a production private key is accidentally exposed outside its intended environment, treat rotation as an operational security decision—not as a formatting problem.
Decodable Base64 Does Not Prove the Label Is True
Any byte sequence can be Base64-encoded and placed between BEGIN CERTIFICATE boundaries. A text formatter can prove that those bytes round-trip through Base64, but it has not proven they form the ASN.1 Certificate structure implied by the label.
Use the PEM Certificate Viewer for field inspection and cryptographic/X.509 tooling for chain, signature, hostname, revocation or key-match questions.
Legacy PEM Headers Are Not Part of RFC 7468 Textual Encoding
Older PEM-style encrypted key files can contain lines such as Proc-Type: and DEK-Info: between the boundary and encoded data. RFC 7468 explicitly distinguishes its textual encoding from legacy PEM and does not define those encapsulated headers.
The parser reports header-like body lines rather than silently treating punctuation from them as Base64.