PEM Certificate Decoder: Who Benefits and Why
Reviewed by the OnlineFree.app team · Updated
Key points
- The PEM Certificate Decoder parses certificates and CSRs in the browser, so certificate text never leaves the page.
- The validity badge marks a certificate Valid, Expiring soon under 30 days, or Expired, with days remaining shown.
- A wildcard SAN covers exactly one label: *.example.com matches api.example.com but not a.b.example.com.
- Decoding is not validation; chain building, hostname checks and revocation must be confirmed elsewhere.
- Never paste a PRIVATE KEY block into any online decoder, including this one.
Who benefits from a PEM Certificate Decoder
Sysadmins, DevOps engineers and web developers get the most from the PEM Certificate Decoder, because they are the people who end up holding a certificate blob mid-incident and need to know what it says in seconds. It turns opaque base64 into a readable field table plus a validity and SAN summary, with no upload and no login.
We built it for the clipboard case. You copy a certificate out of a load balancer config, a Kubernetes secret dump or a support ticket, paste it into the textarea and press Decode. The parse runs client-side in JavaScript, so the certificate text never leaves the page. Dropped .pem, .crt, .cer or .csr files are read with the browser's FileReader API, again locally, and the textarea is filled in so you can confirm what was loaded before you trust the result.
That local-only design matters more than it first sounds. Certificates are public by definition, but pasting production material into arbitrary websites is how internal hostnames, SAN inventories and organisational structure leak. Keeping the parse in the browser makes the habit safe — provided what you paste really is a certificate and not a private key. The tool is one of several utilities on OnlineFree.app that follow the same no-upload rule.
What the certificate fields table tells you
Each decoded block produces a key/value table with a copy button on every row, so values can go straight into a ticket or change record without retyping. You get the X.509 version (almost always v3), the serial number, the signature algorithm such as sha256WithRSAEncryption, the subject and issuer distinguished names, the public key algorithm and size, and both SHA-256 and SHA-1 fingerprints.
The subject DN is split into CN, O, OU, C, ST and L so you don't have to eyeball a slash-separated string, while the issuer DN stays intact for comparison. The public key row is where you confirm whether you are looking at RSA 2048, RSA 4096 or an elliptic-curve key such as prime256v1, which is the fastest way to catch a key size that falls short of your own policy.
Two misreadings show up constantly. The first is treating the issuer as the owner: for a leaf certificate the subject is your domain and the issuer is the intermediate CA that signed it. The second is treating the serial number as globally unique — it is unique within a given issuer, not across the world, so quote it together with the issuer when you escalate. The SHA-1 fingerprint is included for legacy matching only; use the SHA-256 value when comparing against a known-good copy, which is the digest described in RFC 5280.
How do you read the SAN list and validity window?
The status strip above the table answers the question people actually have: is this certificate still usable? It shows notBefore and notAfter converted to your local time, the number of days remaining, and one of three badges — Valid, Expiring soon when fewer than 30 days remain, or Expired. The 30-day threshold is a fixed part of the tool's logic, not a prediction of when your CA will renew.
Below that sits the Subject Alternative Name list, grouped by type: DNS names, IP addresses, email addresses and URIs. Wildcard entries are called out explicitly because they are the most common source of confusion. A SAN of *.example.com matches api.example.com but does not match a.b.example.com, and it does not match the bare example.com either — that needs its own entry.
The usual mistake is a timezone mix-up. Certificates store validity in UTC, and the panel converts to local time, so an expiry at 00:00 UTC can appear as the previous evening in the Americas. Another is assuming a Valid badge means the certificate works: a currently valid leaf still breaks if the intermediate that signed it is missing from the server's chain. IP-based access also needs an IP SAN; a DNS name in the SAN does not cover https://203.0.113.10.
Why CSRs are decoded differently
A CSR is a PKCS#10 request, not a certificate, so it has no issuer and no validity period. When you paste one into the PEM Certificate Decoder, the validity panel reads 'not applicable' and only the requested SANs are listed. What you can still check is the subject, the public key algorithm and size, the signature algorithm, and every name you asked the CA to include.
That makes the tool useful before submission rather than after. A typo in a requested SAN costs a reissue, and mismatched key sizes against an internal policy get caught here rather than at deployment. Compare the CSR's subject and SANs against the configuration that generated it, then compare again against the issued certificate once it comes back.
The mistake we see most is pasting a CSR into a certificate checker, seeing no dates, and assuming something is broken. The other is treating requested SANs as granted SANs — a CA may drop or refuse entries, so the issued certificate is the authoritative record.
Where the decoder stops — verify trust elsewhere
The tool decodes; it does not validate. Chain building to a trusted root, hostname matching against a live TLS connection, revocation checking via OCSP or CRL, and Certificate Transparency lookups are all out of scope. A Valid badge means the current time falls between notBefore and notAfter and nothing more — it says nothing about whether a browser will accept the certificate.
For anything that matters, confirm with a second tool. openssl x509 -noout -text -in cert.pem prints the same fields locally on your own machine, and your CA's portal or your browser's certificate viewer settles the trust question. The decoder also has practical limits worth knowing: it decodes the first PEM block it finds, lists any additional blocks as detected blocks, and caps input at roughly 1 MB.
One rule is absolute: never paste a PRIVATE KEY block into any online decoder, this one included. The parser expects certificates and CSRs, and a key block in a shared clipboard is a security incident waiting to happen. If your team needs extra fields or an internal variant, that is the kind of request we handle through a custom PRD build.
Frequently asked questions
Does the PEM Certificate Decoder upload my certificate to a server?
No. The PEM Certificate Decoder parses everything in your browser with JavaScript, so the certificate text never leaves the page, and no account or sign-up is required. Files you drop onto the page are read locally with the browser's FileReader API. The one thing you should never paste is a PRIVATE KEY block — the tool decodes certificates and CSRs, not private keys.
Can the PEM Certificate Decoder tell me if a certificate is trusted by browsers?
No. It decodes fields and compares dates against your current time, but it does not build a chain to a trusted root, check revocation or verify the signature against a trust store. A Valid badge only means the current time sits between notBefore and notAfter. Use your browser's certificate viewer, your CA's portal or openssl on the server to settle trust.
Why does my CSR show no expiry date in the PEM Certificate Decoder?
Because a CSR is a PKCS#10 request rather than an issued certificate, and it never contains a validity period or an issuer. The decoder shows validity as not applicable for CSRs and lists only the SANs you requested. Compare those requested names and the key size against the certificate the CA eventually issues, which is the authoritative record.
What is the difference between the SHA-1 and SHA-256 fingerprints in the output?
Both are digests of the certificate's DER encoding, just with different hash functions. Use the SHA-256 fingerprint for any comparison that matters, since it is the value modern inventories and monitoring tools expect. The SHA-1 value is shown so you can match older documentation or legacy systems that still print it, not as a security check.
How many PEM blocks can I paste at once?
Roughly 1 MB of text, and the decoder parses the first block it finds while listing any others as detected blocks. If you need to inspect a full chain, paste the certificates one at a time, leaf first. For a pasted chain, the first block is normally the leaf, which is the one whose SANs and expiry you usually care about.