What does a certificate decoder do?
A certificate decoder reads the ASN.1 structure inside an X.509 certificate and prints its fields in a form a person can check. It shows the subject and issuer distinguished names, the validity window, the public key and its size, the serial number, the signature algorithm, the subject alternative names the certificate is actually valid for, every extension with its critical flag, and the SHA-256 and SHA-1 fingerprints of both the certificate and its public key. All of it is computed from the bytes you paste.
A certificate is DER — a binary, tag-length-value encoding defined by ASN.1 — usually wrapped in Base64 text with BEGIN CERTIFICATE lines around it. Neither form is readable by eye, and the text armour only makes it transportable, not legible. The decoder walks the tree, decodes the primitives and reorders them by what a reader wants rather than by how the encoding happens to store them, which is the difference between a wall of hex and a page you can scan.
What it does not do is tell you whether to trust the certificate. Trust is decided by a chain to a root the browser already has, by revocation status, and by whether the host name being connected to appears in the alternative names — none of which is inside the file. A decoder shows what was claimed. The one exception here is a self-signed certificate: for those the tool also verifies the signature, because the key needed to check it is the one the certificate carries.
How to read a certificate
- Paste the certificate text — the whole PEM block including the BEGIN and END lines — or open a .crt, .cer, .der or .pem file.
- Press Read the certificate; the fields appear grouped rather than in encoding order.
- Check the subject and issuer first: identical names mean it is self-signed, and different names show who issued it.
- Read the validity window and the validity note, which says plainly whether the certificate has expired or is not yet valid.
- Look at the subject alternative names — that list, not the common name, is what a browser matches a host against.
- Skim the extensions for anything marked critical, then copy the fingerprint or the public key if you need to compare it elsewhere.
Certificate Decoder limits and rules
| Item | Limit |
|---|---|
| Input | PEM text, bare Base64, or a raw DER file; up to 4 MB |
| Certificates | X.509 version 3, which is what publicly trusted certificates are |
| Decoded | Subject, issuer, validity, serial, signature algorithm, key and every extension |
| Extensions | SAN, key usage, basic constraints, extended key usage, key identifiers, AIA, CRL points and policies are spelled out; others show raw bytes |
| Fingerprints | SHA-256 and SHA-1 of the certificate, and SHA-256 of its public key |
| Signature check | Only for self-signed certificates, where the key needed is inside the file |
| Not covered | Chain building, root-store trust, revocation lookup and host-name matching |
When to use it
- Confirming which host names a certificate actually covers before a deployment.
- Checking the expiry date of a certificate on a server you are about to leave alone.
- Comparing a SHA-256 fingerprint against one printed by the issuer.
- Seeing whether a certificate is self-signed or issued by a known authority.
- Finding a critical extension that a client is required to understand.
Is it private?
The bytes you paste are parsed by JavaScript in this page. Nothing is uploaded, stored or logged, and the certificate is discarded when you close the tab. A certificate is public by design, but there is no reason for it to travel to a server in order to be read.
Frequently asked questions
Because trust is not a property of the file. A certificate is trusted when it chains to a root a client already has in its store, when none of the certificates in that chain have been revoked, and when the host name being connected to is in the alternative names. Every one of those checks needs information from outside the certificate — the intermediate certificates, a revocation list or OCSP responder, and the name of the server you are talking to. A decoder that claimed to answer it would be guessing.
Because browsers stopped reading the common name for host matching in 2017 and use only the subject alternative names. Since then, public authorities will not issue a certificate on the common name alone, and a certificate whose CN is right but whose SAN list is empty or different is treated as not covering the name. This is the single most common reason a certificate looks correct in a decoder and fails in a client, and it is why the alternative names are shown separately and prominently here.
It means the certificate cannot be accepted by anything that does not understand that extension. Criticality is an instruction to the reader: process this, or refuse the certificate. Non-critical extensions may be ignored by a client that does not recognise them. In practice most extensions are not critical, so seeing the flag is worth noting — a certificate carrying an unfamiliar critical extension will be rejected by some clients even though it looks otherwise fine.
One is a digest of the whole certificate file, and the other is a digest of just the public key inside it. The certificate fingerprint changes if any byte — a date, a name, an extension — differs, which makes it suitable for telling two certificates apart or pinning exactly one. The public-key fingerprint stays the same across a renewal that reuses the same key, so it identifies the key rather than the document. Both are computed here from your bytes, so neither is looked up from anywhere.
Only the first block is read. Certificates are often distributed as a chain — the leaf, then one or more intermediates — inside a single file, and each block is a separate certificate with its own boundary lines. Paste just the leaf to read the server certificate, and each intermediate separately if you want to inspect them. The ssl-converter tool on this site converts the same material between PEM and DER, which is useful when a chain needs splitting out.
For a self-signed certificate, yes, because the key it was signed with is the one it carries. For anything else, no — a certificate is signed by its issuer, and the issuer's key is in a different file. Checking the signature of an issued certificate means fetching the issuer's certificate and using this same verification against its public key, which is what a chain-validation library does. The tool reports the self-signature result explicitly and says nothing about the rest.
Related tools
Written and maintained by Md. Nur Hossain Repon.