A complete guide to decoding X.509 certificates, understanding each result field, and why certificate fingerprints matter in practice.
Launch the Certificate Decoder →The Certificate Decoder takes a PEM-encoded X.509 certificate — the kind of file you'd find protecting any HTTPS website, or one generated by this site's own SSL Self-Signed Certificate Tool — and parses it into a clear, human-readable breakdown: subject fields, issuer fields, validity period with a clear expired/valid/not-yet-valid status, public key algorithm and size, signature algorithm, serial number, SHA-256 fingerprint, and any Subject Alternative Names included in the certificate.
This is a pure parsing and inspection tool: it reads and interprets an existing certificate's contents without modifying, validating against a trust chain, or verifying it against any Certificate Authority. It answers the question "what exactly does this certificate say about itself," which is a genuinely common need whenever you're handed a certificate file and want to quickly understand its details without digging through command-line tools.
Certificates are binary, ASN.1-encoded structures underneath their PEM text wrapper (a Base64-encoded representation framed by -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers), which means their actual contents aren't human-readable just by looking at the raw file. Traditionally, inspecting a certificate's details required a command-line tool like OpenSSL, which, while powerful, has a learning curve and isn't always conveniently available, especially on a locked-down work computer or when you just need a quick answer.
Common real-world reasons to decode a certificate include: confirming exactly when a certificate expires before it causes an unexpected outage, verifying that a certificate's Subject Alternative Names actually cover all the domain names you need it to protect, checking which Certificate Authority issued a certificate, confirming a certificate's key size and algorithm meet a security policy requirement, or simply double-checking that a certificate you just generated (with this site's own certificate tools, or elsewhere) actually contains the fields you intended.
Subject fields describe the entity the certificate was issued to — for a website certificate, this is typically the domain name (as the Common Name) along with organizational details. Issuer fields describe the Certificate Authority (or, for a self-signed certificate, the same entity as the subject) that signed the certificate.
Validity shows the Not Before and Not After dates defining the certificate's valid lifetime, along with a clear status indicator: Valid (with the number of days remaining), Expired, or Not Yet Valid, calculated by comparing those dates against your device's current system clock.
Public Key Algorithm and Key Size report what kind of cryptographic key the certificate contains and how large it is — this tool's underlying library, node-forge, parses RSA keys fully and reports their exact bit length, but is honest about not fully parsing elliptic curve (EC) public keys, a limitation explained further below. Signature Algorithm identifies which hash and encryption algorithm combination was used by the issuer to sign the certificate, such as SHA-256 with RSA.
Serial Number is a unique identifier assigned by the issuing Certificate Authority, used (among other purposes) for certificate revocation tracking. SHA-256 Fingerprint is a cryptographic hash of the certificate's entire DER-encoded binary content, calculated locally by this tool, which serves as a unique, tamper-evident identifier for that exact certificate — useful for confirming you have the exact certificate file you expect, since any modification to the certificate would produce a completely different fingerprint.
This tool directly discloses, both in its results and here, that it does not fully parse elliptic curve (EC/ECDSA) public key details the way it does for RSA keys. When a certificate using an EC public key is decoded, the Public Key Algorithm field will indicate this limitation rather than silently showing incorrect or fabricated information.
This reflects the underlying node-forge library's own design and documented focus: it was built with particularly strong, mature support for RSA key structures, including straightforward access to properties like the key's modulus bit length, but its EC key parsing support is comparatively limited. Rather than attempting to work around this with a separate, independently-verified parsing path for EC keys specifically for this one field, the honest choice was to clearly flag the limitation rather than risk presenting unverified or potentially incorrect key size information.
-----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers.Decoding a certificate for a multi-domain website might reveal a Common Name of example.com alongside Subject Alternative Names including www.example.com and api.example.com, confirming the single certificate properly covers all three hostnames rather than needing separate certificates for each.
The SHA-256 fingerprint displayed by this tool is worth understanding beyond just "a unique identifier," because it serves several genuinely practical security purposes in real-world situations:
All certificate parsing happens entirely within your browser using the node-forge library loaded from a public CDN. No network request involving the certificate's actual content is ever made — the certificate you paste is never transmitted anywhere, logged, or stored by NexTechTools.
Because certificates are, by their fundamental nature as X.509 documents, meant to be public (they're transmitted to every visitor connecting to an HTTPS website, for instance), there's generally no sensitivity concern with the certificate content itself, though this tool treats it with the same no-logging, no-storage privacy standard as every other tool on this site regardless.
No, this tool specifically expects a PEM certificate (beginning with -----BEGIN CERTIFICATE-----). A private key file has a different PEM header and would need to be decoded with a different tool built specifically for that purpose.
This happens when the certificate uses an elliptic curve (EC/ECDSA) public key rather than RSA. As explained in the EC limitation section above, this tool's underlying library does not fully parse EC key details, and honestly reports this rather than guessing.
No. This tool only reads and displays what the certificate itself claims about its subject, issuer, and validity — it does not verify the certificate against any trust chain, check for revocation, or confirm the issuing Certificate Authority is legitimate.
Validity dates define the time window during which the certificate is intended to be considered valid. The fingerprint is an entirely separate, content-based cryptographic hash used to uniquely identify that exact certificate file, independent of time — it would change if even a single byte of the certificate were different.