How to Use the PEM Certificate Decoder, Step by Step
Reviewed by the OnlineFree.app team · Updated
Key points
- The PEM Certificate Decoder parses pasted PEM certificates and CSRs entirely in the browser, with no upload step.
- Its Validity & SANs panel shows days remaining plus a Valid, Expiring soon (under 30 days) or Expired badge.
- Subject DN components, key size, serial number and SHA-256/SHA-1 fingerprints are split into a copyable table.
- Hostname matching uses the SAN list, not the subject CN, so always read the SANs before assuming a certificate fits.
- It decodes only what you paste — it does not verify chains, check revocation or replace openssl for security-critical work.
What is the PEM Certificate Decoder?
The PEM Certificate Decoder is a browser-only tool that turns pasted PEM or CSR text into a readable field table — subject, issuer, validity dates, key algorithm and size, SHA-256 and SHA-1 fingerprints — plus a validity badge and the full Subject Alternative Name list. Nothing is uploaded: the Base64 block is parsed inside the page, so the certificate text never leaves your browser.
A PEM file is just Base64 wrapped in BEGIN/END header lines, a format standardised in RFC 7468. That makes it copy-safe but unreadable, which is why people paste blobs into a decoder at 2 a.m. when a site throws NET::ERR_CERT_DATE_INVALID or a CA distrust notice lands in Slack.
We built the tool for that exact moment. Paste the block or drop a .pem, .crt, .cer, .csr or .txt file and the section below the input fills in immediately with the decoded values — no sign-up, no round trip to a server, no waiting for a CLI to start.
How do you decode a certificate step by step?
Start by copying the whole block, header and footer included, into the monospace box labelled "Paste PEM / CSR". It also accepts raw Base64 without headers, plus multiple PEM blocks — the first block is decoded and the rest are listed as detected blocks, which matters when you paste a full chain bundle.
If the text is in a file, drop it on the zone under the textarea. Files up to 1 MB are read with the browser FileReader and copied into the textarea so you can confirm exactly what was loaded before decoding. The textarea itself is capped at roughly 1 MB of text, which is far more than a leaf certificate or CSR needs.
Press the Decode button. The result area stays empty until a valid block parses, then shows a status strip at the top and two stacked cards: the fields table and the Validity & SANs panel. If the block is truncated or mislabelled you get an error line instead of a half-decoded table, and Clear resets everything.
Every row in the table has its own copy button, so you can drop the serial number or SHA-256 fingerprint straight into a ticket without retyping it and introducing a transcription error. If you need to compare two certificates, decode one, copy what you need, clear, then decode the next.
Reading the certificate fields table
The table splits the subject distinguished name into its components — CN, O, OU, C, ST and L — instead of leaving you to parse a comma-joined string. For an ordinary TLS certificate you will typically see a CN like example.com, an organisation, and a country code, while the issuer DN tells you which CA signed it.
Alongside those you get the version (usually v3), the serial number, the signature algorithm such as sha256WithRSAEncryption, and the public key algorithm with its size in bits — 2048-bit RSA and 256-bit ECDSA are the common values. The SHA-256 and SHA-1 fingerprints are computed from the DER encoding and printed in the usual colon-separated hex form.
That combination answers most incident questions quickly: is this the certificate I think it is, did the CA I expect actually issue it, and is the key size what our policy requires? The structure of these fields follows X.509 as profiled in RFC 5280, so the names map directly to what openssl x509 -text prints.
Check validity and SANs before you trust it
The Validity & SANs panel converts notBefore and notAfter into your local time and adds a days-remaining count, then labels the certificate Valid, Expiring soon when fewer than 30 days remain, or Expired. The 30-day threshold is a deliberately conservative default — for a public site with automated renewal you may want to act well before the badge turns amber.
Under the dates you get the complete Subject Alternative Name list, with each entry tagged as DNS, IP, email or URI, and wildcard entries called out separately. This is the list modern clients actually match against; a common name in the subject alone is not enough for hostname validation, which is a frequent source of "the certificate is valid but the browser still complains" confusion.
For a CSR the panel shows validity as not applicable and lists only the SANs being requested. That is the right behaviour — a signing request has no dates yet — and it makes the tool useful for catching a missing SAN before you spend a validation cycle on a rejected request.
Common mistakes when reading a certificate
The most frequent error is pasting a fragment: a block missing its END line, or only the Base64 body with a stray blank line in the middle. PEM is line-sensitive in practice, so re-copy from the BEGIN header to the END footer and try again. A mismatched header, such as a CERTIFICATE header around CSR content, also fails to parse.
Second, people decode the leaf and forget the intermediate. If the chain looks broken, paste each certificate separately and compare the issuer DN of the leaf against the subject DN of the intermediate — they must match exactly, including whitespace inside values. This tool decodes what you give it; it does not build or verify a chain, and it does not check revocation via OCSP or CRL.
Third, expiry is not the only failure mode. A certificate can be valid but not yet active if notBefore sits in the future, which happens with clock skew or a freshly issued certificate on a machine with a wrong system time. Read both dates, not just the expiry. Always confirm anything security-critical against your own system tools before acting.
Is it safe to paste a certificate here?
Parsing happens entirely in the page with JavaScript, so the PEM text is never transmitted, stored or logged by us. That is the reason the decoder exists as a client-side tool rather than an API: certificate material often carries internal hostnames, and CSRs can contain organisation details you would rather not hand to an unknown server.
One rule still applies: paste certificates and CSRs only. A private key block beginning with BEGIN PRIVATE KEY or BEGIN RSA PRIVATE KEY has no business in any web page, including ours — the decoder is designed for public certificate material and signing requests.
If you want the same local-only behaviour for related formats, the PEM Certificate Decoder sits alongside the other free online tools on OnlineFree.app, all of which run in the browser without an upload step.
Frequently asked questions
Does the PEM Certificate Decoder upload my certificate anywhere?
No. The PEM Certificate Decoder parses the pasted text with JavaScript inside your browser tab, so the certificate never travels to a server, is never stored, and is not logged. The trade-off is that you must keep the tab open to keep the results, and nothing is saved between visits.
Can the PEM Certificate Decoder read a CSR as well as a certificate?
Yes. Paste a PKCS#10 CSR and you get the requested subject, key algorithm and size, signature algorithm and the SANs being requested. The validity panel shows "not applicable" because a signing request has no notBefore or notAfter dates yet, so only the SAN list is meaningful.
What does the "Expiring soon" badge mean?
The badge appears when the certificate's notAfter falls within 30 days of today, and the panel shows the exact number of days remaining in your local time. It is a fixed threshold, not a policy engine, so adjust for your own renewal window — automated renewals often need far more notice.
Which file types can I drop into the PEM Certificate Decoder?
The drop zone accepts .pem, .crt, .cer, .csr and .txt files up to 1 MB. The file is read as text and placed into the textarea so you can check it before decoding. Chain bundles work too: the first PEM block is decoded and any additional blocks are listed as detected.
Does the PEM Certificate Decoder verify the certificate chain or check revocation?
No. It decodes the fields and dates of the block you paste and stops there; it does not build a chain, validate signatures or query OCSP or CRL endpoints. Use it to read and compare certificates quickly, then confirm chain and revocation status with your own PKI tooling before making a security decision.