SSL Certificate Decoder: Read PEM & X.509 Details

Inspect a PEM/DER certificate's subject, issuer, validity, SANs, signature algorithm, and fingerprint entirely client-side.

This reads the raw ASN.1 DER structure of an X.509 certificate itself, using a small hand-written parser rather than a third-party crypto library, so pasting a PEM block gets you the subject, issuer, validity window, and public key details straight from the bytes rather than from a summary someone else's tool decided to show. Paste a full chain and each certificate in it gets parsed and labeled independently.

How to decode an SSL certificate

  1. Copy the certificate text including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines, or copy an entire chain file such as fullchain.pem or a CA bundle.
  2. Paste it into the certificate box. Decoding starts as soon as the text changes, so there is no button to press and no file to pick.
  3. Read each panel: subject, issuer, Not before and Not after dates in UTC, Subject Alternative Names, public key and signature algorithms, serial number, and the SHA-256 fingerprint.
  4. Check the badge in each panel header — "Expired N days ago", "Expires in N days" when fewer than 30 remain, or "Valid" — and confirm the leaf, intermediate and root labels follow the order you pasted.

What actually gets parsed out of the certificate

What a PEM certificate looks like

PEM is the text wrapping of a binary DER certificate: the DER bytes are base64-encoded, usually broken into 64-character lines, and fenced by -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers. Files ending in .pem and .crt almost always hold this text form, while .cer and .der files can be either text or raw binary, so open one in a plain text editor first — readable base64 means you can paste it here.

The decoder pulls out every BEGIN/END CERTIFICATE block it finds and ignores whatever text sits between them, which means you can paste the raw output of openssl s_client -showcerts, subject and issuer comment lines included. A bare base64 string with no markers is also accepted and decoded as one certificate. Binary DER cannot be pasted as text, so convert that kind of file to PEM first with the OpenSSL command below.

What it deliberately doesn't claim to show

The extension-parsing logic here targets exactly one extension: Subject Alternative Name. Key Usage, Extended Key Usage, Basic Constraints, and every other X.509 extension are present in the certificate's raw bytes but not decoded or displayed by this parser — if a field isn't listed above, it isn't something this tool extracts, and no other extension should be inferred from what it does show.

A hand-rolled DER reader that only implements the fields it needs is a smaller, more auditable piece of code than a general-purpose ASN.1 library, but it's also narrower in what it exposes. If you need Key Usage or a full extension dump, a dedicated OpenSSL command against the same certificate will show more than this page does.

Why "self-signed" here means the names match, not that trust was verified

A certificate is labeled self-signed when its subject distinguished name is textually identical to its issuer distinguished name. That is a real and common signal — root CA certificates are always self-signed in exactly this sense — but it is a string comparison of two decoded names, not a cryptographic check that the certificate's signature was actually produced by its own public key.

When you paste a full chain, each certificate is parsed independently and positioned as leaf, intermediate, or root based purely on paste order plus that same name-match check on the last entry. This tool does not verify that each certificate in the chain was actually signed by the next one's private key — it shows you what each certificate claims about itself, which is a different, narrower guarantee than validating the chain of trust a browser performs during a real TLS handshake.

Reading the expiry status correctly

Every parsed certificate gets flagged as expired, expiring within 30 days, or valid, compared against your own machine's current clock at the moment the certificate is decoded and displayed. If your system clock is wrong, this status will be wrong in exactly the same way, since there's no external time source involved.

This status only reflects notBefore and notAfter. A certificate can show as valid by dates while still being revoked, mis-issued, or otherwise untrustworthy for reasons this tool has no way to check — revocation status requires an OCSP or CRL lookup against a live network endpoint, which this offline, zero-upload tool intentionally never performs.

Decode a certificate with OpenSSL instead

Questions people ask about SSL/TLS Certificate Decoder

Can I decode an expired or revoked certificate?
Expired certificates decode exactly like current ones; the panel header just shows an "Expired N days ago" badge beside the dates. Revocation is invisible here, because checking it needs a live OCSP or CRL request to the issuing CA and this tool never makes a network call, so a revoked certificate looks like any other.
Why does it say my certificate is self-signed when I know it's from a real CA?
Self-signed here specifically means the subject name and issuer name inside the certificate are identical text — true for root CA certificates by design, and also true for any certificate where those two fields happen to match. If you pasted a leaf certificate and it's flagged self-signed, check that you pasted the certificate you meant to and not its issuing root.
Can I see the Key Usage or Extended Key Usage extensions?
Not with this tool. Its DER parser only decodes Subject Alternative Name from a certificate's extension list; Key Usage, Extended Key Usage, and other extensions exist in the certificate's raw bytes but aren't extracted or shown here. Use OpenSSL's x509 -text output against the same PEM if you need those fields.
Is pasting a private certificate chain here safe?
The parsing happens entirely client-side in your browser with no network request involved, so the certificate content never leaves your machine. Certificates are, by design, meant to be public anyway — the sensitive half of a TLS key pair is the private key, which this tool never asks for and would have no use for.
What information does an SSL certificate contain?
An X.509 certificate holds the subject it was issued to, the issuing CA, a notBefore and notAfter validity window, the subject's public key, a serial number, the CA's signature and its algorithm, and extensions such as Subject Alternative Name, Key Usage and Basic Constraints. This page shows all of those except the extensions other than SAN.
Can this tool decode a CSR or private key?
No, it reads X.509 certificates only. A -----BEGIN CERTIFICATE REQUEST----- block is not decoded and produces an error panel instead, and a private key block is rejected as invalid input. Inspect a CSR with openssl req -in request.csr -noout -text, and keep private keys out of web pages altogether.
What should I do if my certificate details are wrong?
A certificate is signed by its CA, so no field can be edited after issuance. If a hostname is missing from the SANs or the organization name is wrong, create a new CSR with the correct details and ask your CA to reissue; first confirm you pasted the certificate you actually deployed.

Related tools on BrakeTools

Content reviewed 2026-09-27.