PEM Certificate Decoder vs. the alternatives: which one should you paste into?
Reviewed by the OnlineFree.app team · Updated
Key points
- PEM Certificate Decoder parses certificates and CSRs entirely in the browser, so pasted material never leaves the page.
- Decoding shows fields, dates and SANs; it does not verify the chain or prove a certificate is trusted.
- Paste chain bundles one block at a time, because only the first PEM block is decoded.
- A SHA-256 fingerprint is the fastest way to confirm you hold the certificate you expect.
- The Expiring soon badge fires below 30 days remaining; it is a reminder, not a policy.
What does a PEM Certificate Decoder actually do?
A PEM Certificate Decoder turns the base64 text between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- into a readable field table: version, serial number, signature algorithm, subject and issuer distinguished names, public key algorithm and size, SHA-256 and SHA-1 fingerprints, validity dates, and the full Subject Alternative Name list. The encoding itself comes from RFC 7468; the fields inside follow the X.509 structure in RFC 5280.
The PEM Certificate Decoder on OnlineFree.app does that parse in the browser tab. You paste the blob or drop a file, press Decode, and get two stacked cards: a Certificate Fields key/value table and a Validity & SANs panel. Nothing is submitted to a server, and each row has a copy button so you can paste a fingerprint or a subject DN straight into a ticket.
It also accepts PKCS#10 certificate signing requests, so you can read a .csr before sending it to a CA instead of after the certificate comes back wrong. Headerless base64 works too — if you strip the BEGIN/END lines, the decoder still finds the DER payload.
How no-upload decoding compares to other options
There are three practical ways to read a PEM file: the openssl command line, a hosted decoder that sends the blob to a server, and a page that parses it locally in JavaScript. All three produce the same field names because they read the same structure. The real difference is where the bytes end up and how much scrolling you do to find the SANs.
Running openssl x509 -in cert.pem -text -noout keeps everything on your machine, but it assumes a shell with the toolchain installed and gives you an indented dump where the SAN block sits far below the metadata. We built this decoder for the middle of an incident, when you have the PEM in your clipboard and want the dates and hostnames on one screen.
Server-side decoders are fine for a public leaf certificate — that material is public by design. They get uncomfortable once you paste an internal CA certificate with a subject DN that leaks a data-centre naming scheme, or a CSR for a service that is not announced yet. A local parse sidesteps the question entirely.
One honest caveat: no browser decoder, including ours, is a substitute for the command line if you are scripting. For repeatable checks across a fleet of hosts, openssl or a certificate monitoring tool will always win.
Three steps from clipboard to field table
Paste the PEM text into the monospace box labelled Paste PEM / CSR, or drop a file onto the zone underneath it — .pem, .crt, .cer, .csr and .txt are accepted up to about 1 MB. Dropped files are read with the browser's FileReader and placed back into the textarea, so you can confirm you picked the right one before decoding.
Press Decode and read the status strip first: it tells you Valid, Expiring soon or Expired, plus the days remaining. Under it, the Certificate Fields card lists version, serial, signature algorithm, the subject DN split into CN, O, OU, C, ST and L, the issuer DN, the public key algorithm and size, and the SHA-256 and SHA-1 fingerprints.
For a chain bundle, remember that only the first PEM block is decoded — the rest are listed as detected blocks. To check each link, copy them out one at a time and paste them separately. A common mistake during a broken-chain incident is decoding only the leaf and never looking at the intermediate's own expiry.
How do you read the validity badge and SAN list?
The Validity & SANs panel shows notBefore and notAfter in your local time zone, not the CA's, which is why a certificate that expires on a Friday can read as expiring on a Saturday if your machine sits on the wrong side of midnight in UTC. Days remaining is calculated from that local rendering.
The badge has three states: Valid, Expiring soon at under 30 days remaining, and Expired. That 30-day cut-off is our own convention, not a rule from the standard — treat it as a nudge to open a renewal ticket. Where lead time matters, many teams set their own alerts at 60 or 45 days.
The SAN list is printed in full and split by type: DNS names, IP addresses, email addresses and URIs, with wildcard entries called out. Check it against what clients actually request, because browsers stopped falling back to the subject CN for hostname matching years ago — a certificate with the right CN and an empty SAN will still fail. For a CSR, validity reads not applicable and only the requested SANs appear.
Where decoding stops and verification starts
Decoding is not validation. The decoder shows you what a certificate claims; it does not build a chain to a trusted root, verify the issuer's signature, consult OCSP or a CRL, or tell you whether any given client trusts the root. A green Valid badge means the dates are current, nothing more.
When the question is trust rather than fields, finish the job elsewhere: openssl verify -CAfile chain.pem cert.pem checks a chain locally, and a browser or your platform's trust store answers whether a root is in the trusted set — useful during a CA distrust announcement. Confirm the fingerprint out of band if you are pinning anything.
For quick one-off lookups on OnlineFree.app, the practical rule is simple: paste certificates and CSRs freely, never paste private keys (a BEGIN PRIVATE KEY block is not a certificate and should not be pasted into any decoder), and verify anything that ends up in production documentation against a second source.
Frequently asked questions
Does PEM Certificate Decoder upload my certificate to a server?
No. PEM Certificate Decoder parses the pasted text or dropped file entirely in your browser using client-side JavaScript, so the certificate never leaves the page. You can confirm this by going offline after the page loads and decoding a PEM blob. That makes it suitable for internal CA certificates and CSRs you would rather not hand to a third-party server.
Can PEM Certificate Decoder decode a CSR as well as a certificate?
Yes. It accepts PKCS#10 certificate signing requests and shows the requested subject DN, public key algorithm and size, and the requested Subject Alternative Names. Because a CSR has no issuer and no validity window, the validity badge reads not applicable and no fingerprints of a signed certificate are shown. Use it to check SANs before submitting to the CA.
Why does PEM Certificate Decoder show only one certificate from my bundle?
The decoder parses the first PEM block it finds and lists any additional blocks as detected, not decoded. That covers full-chain files where leaf and intermediate sit in one file. To inspect each link, paste the blocks one at a time, which also lets you check the intermediate's own expiry date during a broken-chain incident.
Does a Valid badge mean the certificate is trusted?
No. The Valid badge only confirms that the current date falls between notBefore and notAfter. Trust requires the certificate to chain to a root in the client's trust store, the issuer signature to verify, and revocation status to come back clean. Decode here, then verify with openssl verify or your browser before relying on it.
What inputs and limits does PEM Certificate Decoder accept?
It accepts pasted PEM text with or without the BEGIN/END header lines, and files with .pem, .crt, .cer, .csr or .txt extensions, up to roughly 1 MB. Dropped files are read locally and placed into the textarea so you can confirm the contents before pressing Decode. Private key blocks are not certificates and should not be pasted.