SSL Certificate Decoder

Decode an X.509 certificate or a CSR in your browser. Subject, issuer, SAN list, validity with an expiry warning, key type and fingerprints. No upload.

🌐 Español

Drop your file here (.pem, .crt, .cer, .csr, .der, .txt)

🔒 Private by design: your files are processed locally in your browser and never uploaded to any server.

A decoder, deliberately not a validator

There are two different questions you can ask about a certificate. What does it say, and should anyone believe it. Tools that answer the second one need to reach out to a root store and to revocation endpoints, which means a server, which means uploading your certificate somewhere.

This tool answers only the first question, and it can therefore answer it entirely on your own device. Everything printed comes from the file itself. Nothing is fetched, nothing is checked against anything external, and no judgement is offered about whether a browser would accept the certificate.

In practice the first question is the one you usually have. Which host names does this cover, when does it expire, is it the same file the server is actually serving, did the certificate authority put the right organisation name in it. All of that is inside the bytes.

Reading a file

  1. Drop a certificate or a request onto the box. PEM, CER, CRT, CSR, DER and a plain text file containing a PEM block are all accepted, one at a time.
  2. Run it. The encoding is detected, the structure is parsed, and the fingerprints are computed.
  3. Read the report, which arrives as a labelled plain text block.
  4. Download it if you want to keep the decode next to the file.

Three encodings, detected rather than declared

Certificates arrive in whatever shape the system that produced them favoured, and nobody enjoys being asked which one they have.

The PEM form is checked first, since the begin and end marker lines are unambiguous and a binary file containing that exact ASCII string by accident is not a realistic worry. If there are no markers, a long unbroken run of base64 characters is treated as a candidate, but only provisionally: it has to decode and then parse as real structure before it is accepted. If either step fails, the original bytes are used as binary DER instead.

That last fall through is the important one. Treating an unrecognised file as raw DER is the correct guess for anything that is not text, and a genuinely undecodable file still fails at the parsing stage rather than being silently misread.

What the validity block actually tells you

Dates in certificates are printed in the report in a sortable international format rather than a local one, because a certificate discussion usually spans time zones and an ambiguous date has caused more confusion than it has saved characters.

Alongside them is a status line that does the arithmetic for you against the clock on your own device. Anything within 30 days of expiry is flagged as expiring soon, which is not an arbitrary threshold: it is roughly where automated renewal starts attempting, so a certificate that says expiring soon and is not renewing is a certificate with a broken renewal process rather than one that merely needs watching.

Fingerprints, and the file identity question

The most common real task is not reading a certificate at all, it is confirming that the certificate you have in a file is the same one something else is using. Both fingerprints exist for that.

Use SHA-256 for anything that matters. SHA-1 is there only because so many device consoles, older monitoring systems and enterprise management interfaces still print SHA-1 thumbprints, and having both avoids a manual conversion when you are comparing against one of those. If you need a checksum over some other file entirely, Checksum File computes hashes for any file, and for a token rather than a certificate, JWT Decode pulls apart the claims.

The other half of the certificate lifecycle

This tool reads. Its counterpart, CSR Generator, writes: it builds a real certification request with the same underlying libraries, which is the file you send to a certificate authority to get a certificate back. Decoding that request here before you send it is a good habit, since a typo in a subject alternative name is far cheaper to catch before issuance than after.

For the key that sits underneath all of this, SSH Key Generator covers login keys. Everything else is on the dev tools hub.

Frequently asked questions

Does this tell me whether a certificate is trusted?

No, and that is the single most important thing to understand about it. It decodes and prints the fields already inside the file you gave it. It never checks the chain against a root store, never queries revocation through a certificate revocation list or an online status protocol, and never verifies the issuer's signature, because doing that would require the issuer's certificate, which it was never given. A perfectly readable report can describe a certificate no browser would accept.

How does it know whether I gave it a certificate or a CSR?

It tries to parse the bytes as an X.509 certificate first, and only if the structure genuinely does not match that shape does it retry as a certification request. The fallback is triggered by one specific schema mismatch condition and nothing else, so a real parsing problem with a real certificate is not quietly re-labelled as being the wrong file type. The report then names which of the two it decoded in its heading.

What file formats does it accept?

Three encodings, worked out automatically. A PEM block, meaning the text form with the begin and end marker lines, is detected first. Failing that, a long run of bare base64 with no markers is tried, and it is only accepted if it both decodes and parses as valid structure. Failing that, the raw bytes are used directly, which is the right answer for a binary DER or CER file. You do not have to tell it which one you have.

What is in the certificate report?

Version and serial number, the full subject and issuer distinguished names, whether the two are identical and the certificate is therefore self-signed, the not before and not after dates in a sortable format with a plain language status line, every subject alternative name, the public key type and size, the signature algorithm, and both a SHA-1 and a SHA-256 fingerprint of the file's own bytes.

What does the expiry status line say?

One of four things. Not yet valid, with the number of days until it starts. Expired, with the number of days since. Expiring soon, which means 30 days or fewer remaining, with the count. Or valid, with the days remaining. The 30 day window matches the point at which most automated renewal systems start trying, so anything flagged as expiring soon should already be renewing.

Why does a CSR get a signature check when a certificate does not?

Because a certification request is self-signed by definition. The standard requires the requester to prove possession of the matching private key by signing the request with it, so verifying that signature is a check on the file's own internal consistency and needs nothing external. A certificate is signed by its issuer, so checking it would require the issuer's certificate. The report labels the CSR check as an integrity check rather than a statement about trust, and if the browser cannot perform it, the report says so along with the reason.

What are the two fingerprints for?

Comparing files. The SHA-256 fingerprint is the one to use for a genuine match check between what you have and what someone else says they have. The SHA-1 fingerprint is included because a great deal of older tooling, and many device management interfaces, still display SHA-1 thumbprints, so having both saves a conversion step. Both are computed over the same DER bytes the rest of the report was decoded from.

The file was rejected and the page only gives a general failure message. How do I narrow it down?

The shared layout around this tool replaces any specific reason with one fixed sentence, so the detail the decoder worked out does not reach the screen. Work through the likely causes instead. Check the file is complete rather than truncated, check you copied the whole PEM block including both marker lines, and check you have a certificate or a request rather than a private key, since a private key file is a different structure entirely and will not decode here.

Related tools