Contact

Tools  /  Security  /  Certificate / DER Structure Viewer

SECURITY

Certificate / DER Structure Viewer

Decode a PEM certificate into its real Subject, Issuer, validity, public key and X.509v3 extensions -- plus raw ASN.1 structure and SHA fingerprints for any PEM block.

More Security tools

JWT Claims Viewer Checksum Calculator SHA File Checker HTTP Security Header Reference Password Entropy Calculator Hash Generator

What this tool does

Decodes a PEM-encoded X.509 certificate into its actual fields — Subject, Issuer, serial number, validity window, public key algorithm and size, and every v3 extension — written from scratch against a real ASN.1/DER byte reader, not a canned summary. For any other PEM block (a public key, private key, or certificate signing request), it falls back to a generic ASN.1 structure tree (tag/length/value, like openssl asn1parse) plus SHA-1/SHA-256 fingerprints, since those block types don't carry Subject/Issuer/validity fields to decode.

From ASN.1 bytes to real fields

A certificate is DER-encoded ASN.1 — nested tag/length/value triples with no field names in the bytes themselves. Reading "Subject: CN=example.com" out of that requires knowing where X.509 puts the Subject inside the generic SEQUENCE nesting (it's the 6th field of the TBSCertificate SEQUENCE, following an optional version, serial number, signature algorithm, and issuer) — this tool walks that structure field by field per the X.509 spec, rather than just printing the raw tree and leaving you to map it manually.

Subject and Issuer

Both are a Distinguished Name — an ordered set of attributes like CN (Common Name), O (Organization), OU (Organizational Unit), C (Country), ST/L (state/ locality), and emailAddress. When Issuer and Subject are identical, the certificate is self-signed — flagged directly rather than left for you to compare by eye.

Validity window and status

Not Before / Not After are decoded from their raw UTCTime or GeneralizedTime encoding into real dates, then compared against the current time to show a status pill: valid, not yet valid, expiring within 30 days, or expired — the kind of check a browser does silently that's otherwise invisible when you're just staring at a PEM blob.

Public key: algorithm and real size

For an RSA key, the modulus is extracted and its actual significant bit length computed (not assumed from byte count, which can be off by a few bits due to DER's sign-padding byte) — the same "2048-bit" / "4096-bit" figure openssl reports. For an EC key, the named curve is identified from its OID (P-256, P-384, P-521, secp256k1) and the key size read off the curve.

Extensions, decoded

X.509v3 extensions are themselves nested, OID-tagged ASN.1 structures. This tool decodes the common ones instead of leaving them as hex: Subject Alternative Name (DNS names, IPs, emails, URIs), Key Usage (which of the 9 defined bits are set, by name), Basic Constraints (CA: true/false and path length), Extended Key Usage (server auth, client auth, code signing, etc.), Subject/Authority Key Identifier, CRL Distribution Points and Authority Information Access (OCSP/CA Issuer URLs). An extension this tool doesn't have a decoder for yet still shows its OID and raw hex rather than silently disappearing.

Fingerprints

SHA-1 and SHA-256 fingerprints are computed over the full raw DER bytes (the standard definition) using crypto.subtle.digest. A fingerprint is useful for confirming two copies of a certificate are byte-identical — it is not a substitute for actually validating the certificate's signature against a trusted root, which this tool does not attempt.

Loading a certificate

Paste PEM text directly, drag a file onto the text box, or use the upload button — .pem, .crt, .cer, .csr and .key files all work since they're plain text PEM under the hood.

Privacy

Every byte is parsed and every fingerprint is computed entirely in your browser. Nothing is uploaded — there is no server component to this tool at all.

FAQ

Frequently asked questions

Is this the same as "openssl x509 -text"?
It decodes the same fields -- version, serial, issuer/subject, validity, public key, extensions -- using the same X.509 field layout openssl reads, and adds an expiry status pill and SHA fingerprints alongside them. It is a from-scratch browser implementation, not a wrapper around openssl.
Why do I only see an ASN.1 Tree, not a Summary, for what I pasted?
Subject/Issuer/validity/extensions are specific to the X.509 Certificate structure. A public key, private key, or certificate signing request (CSR) is a different ASN.1 structure entirely, so only the generic ASN.1 Tree and Fingerprints tabs apply to those -- the Summary and Extensions tabs need an actual CERTIFICATE PEM block.
What does "self-signed" mean, and is it a problem?
It means the Issuer and Subject fields are identical -- the certificate was signed by its own private key rather than a separate certificate authority. That is completely normal (and expected) for a root CA certificate or a local-dev/test certificate, but a browser will reject it for a public website unless that exact certificate is explicitly trusted first.
Should I trust a SHA-1 or SHA-256 fingerprint as proof the certificate is legitimate?
A fingerprint only proves two copies of the certificate are byte-identical -- it says nothing about whether the certificate itself was properly issued or is trusted. Actual trust comes from verifying the certificate chain up to a trusted root, which this tool deliberately does not attempt; use it to compare fingerprints, not to validate authenticity.
Why do Key Usage and Extended Key Usage matter?
They constrain what the certificate's key is actually allowed to be used for -- Key Usage covers low-level operations (signing, key encipherment, CA signing, etc.) and Extended Key Usage covers higher-level purposes (TLS server auth, client auth, code signing, email). A browser or client will reject a certificate being used outside what these fields permit, even if everything else checks out.
Can I decode a private key or CSR here?
A private key or CSR will show its raw ASN.1 structure (ASN.1 Tree tab) and SHA fingerprint, same as any PEM block, but the Summary/Extensions decoding is specific to X.509 certificates and won't apply.
Is anything I paste or upload sent anywhere?
No. Parsing, field decoding and fingerprinting all happen entirely in your browser with no network request at all -- this tool has no server component.
What happens if the ASN.1 parse fails?
The tool reports that it could not parse the input as valid DER/X.509 rather than showing wrong or partial fields -- usually caused by a truncated paste or a non-PEM input. Check the PEM includes both the BEGIN and END lines and the full base64 body between them.
Theme Accent