SSL Certificate Decoder
Decode an X.509 / SSL certificate to see its subject, issuer, validity dates, SANs, key size, extensions and fingerprints.
Drag & drop a .pem, .crt, .cer or .der file here, or click to browse
No uploads. Your certificate is decoded on your device and never leaves it.
Paste a PEM certificate above (or open a file) — it is parsed as you type, entirely in this browser tab.
Summary
Subject Alternative Names
This certificate has no SAN extension.
Subject
Issuer
Validity
Public key & signature
Fingerprints
X.509 v3 extensions
How it works
Paste a PEM certificate (the -----BEGIN CERTIFICATE----- block), raw Base64 or a
hex dump, or open a .pem, .crt, .cer or binary
.der file. The tool walks the DER/ASN.1 structure of the X.509 certificate by
hand — no crypto library — and reports the subject and issuer Distinguished Names, the
validity window with the exact number of days left, the serial number, the signature
algorithm, the public key type and size, every Subject Alternative Name, and the standard v3
extensions (Basic Constraints, Key Usage, Extended Key Usage, Subject/Authority Key
Identifier, CRL distribution points, Authority Information Access and certificate policies).
If the file contains a chain, pick which certificate to inspect from the dropdown.
SHA-1 and SHA-256 fingerprints are computed over the DER bytes with the browser's built-in
Web Crypto API, so they match what openssl x509 -fingerprint prints. Dates are
shown in UTC, exactly as they are encoded in the certificate's UTCTime or GeneralizedTime
fields. The hostname checker applies the usual TLS matching rules: a name matches a SAN
entry exactly, and a wildcard such as *.example.com matches a single label to
its left (so it covers www.example.com but not
a.b.example.com or the bare example.com).
Everything runs locally. The certificate never leaves your device — there is no upload, no API call and no server involved, so it is safe to inspect internal, staging and client certificates here. A certificate contains only public data, but the private key that goes with it never belongs in an online tool. This decoder reads certificates only; it does not verify the signature against an issuing CA or check revocation, both of which need the issuer's certificate and network access.
Frequently asked questions
How do I decode an SSL certificate?
Paste the certificate's PEM block — everything from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- — into the box, or drag in a .pem, .crt, .cer or binary .der file. The decoder walks the DER/ASN.1 structure straight away and shows the Common Name, the full subject and issuer Distinguished Names, the validity window with the number of days left, the serial number, the signature algorithm, the public key type and size, every Subject Alternative Name and each X.509 v3 extension. Raw Base64 and hex dumps work too, and if the file holds a whole chain a dropdown lets you pick which certificate to inspect.
Is it safe to paste a certificate into an online decoder?
With this one, yes — nothing is transmitted. The parsing runs as JavaScript inside your browser tab and the SHA-1 and SHA-256 fingerprints are computed with the browser's built-in Web Crypto API, so the certificate never reaches a server and there is no upload, API call or logging. Most CA-run decoders POST your certificate to their backend instead. A certificate contains only public information anyway, but internal hostnames and staging domains are still worth keeping off other people's servers. Your private key, on the other hand, should never be pasted into any online tool.
Why does my certificate show as expired or untrusted when the dates look fine?
Expiry is only one of several checks a browser makes. This tool reports exactly what the certificate itself says: the notBefore and notAfter dates in UTC, the days remaining, and whether the hostname you type matches a Subject Alternative Name. A certificate can still be rejected because the name is only in the deprecated Common Name field and not in a SAN, because it is self-signed or issued by a CA your device does not trust, because an intermediate certificate is missing from the server's chain, or because it has been revoked. Verifying the signature and checking revocation both need the issuer's certificate and a network connection, so they are outside what a purely local decoder can do.