PEM certificates, CSRs, and keys → ASN.1 tree + readable fields, all in your browser
| PEM Header | ASN.1 Type | What the Decoder Extracts |
|---|---|---|
CERTIFICATE / X509 CERTIFICATE | Certificate (X.509) | Subject, issuer, serial, validity window + days left, SANs, key size/type, signature algorithm, CA flag, key usages |
CERTIFICATE REQUEST | PKCS#10 CSR | Requested subject, public key, SAN extension (if requested), signature algorithm, challenge password (if present) |
RSA PRIVATE KEY | PKCS#1 | Key size from the modulus, public exponent; structure of the components (no copyable private material shown) |
EC PRIVATE KEY | SEC 1 | Curve, private key length, embedded public point |
PRIVATE KEY | PKCS#8 | Algorithm OID (RSA/EC/Ed25519), underlying key structure |
ENCRYPTED PRIVATE KEY | PKCS#8 (encrypted) | Cipher OID (e.g. aes-256-cbc) and the fact it's encrypted — no decryption attempted |
PUBLIC KEY | SubjectPublicKeyInfo | Algorithm, key size or curve, exponent / public point |
Paste several blocks in one file — a cert chain — and each is decoded separately, in order.
PEM is armor: base64 wrapped in BEGIN/END markers. Stripped of the armor, the bytes are DER, where every value is a tag byte (what type it is), a length, and content. Content of constructed types (sequences, sets, context wrappers) is more tag-length-values, recursively — that recursion is the ASN.1 tree you see. The decoder parses every byte, computes each node's offset and length, names the universal tags, and decodes the leaves it recognizes: integers to hex, object identifiers to dotted notation with their well-known names, UTCTime and GeneralizedTime to real dates, strings to text.
For certificates, the summary walks TBSCertificate: version (v3 shows as [0] wrapper), serial, signature algorithm, issuer and subject names (each RDN in order), validity dates with days remaining computed against your clock, the SubjectPublicKeyInfo (RSA modulus bit length and exponent, or the named EC curve), and the extensions that matter day-to-day — SANs, basicConstraints CA flag, key usage, extended key usage, SKI/AKI. For CSRs it reads the certification request info; for keys it identifies the format and reads the public components.
Decoding a self-signed RSA test certificate issued for 90 days over api.example.com: the serial decodes to a 20-byte integer (shown in hex, e.g. 154E…C9), the subject and issuer both read C=US, ST=California, L=San Francisco, O=Example Corp, CN=api.example.com, and the validity section shows notBefore and notAfter exactly 90 days apart. The SAN extension decodes to two dNSNames (api.example.com, www.example.com), one IP address (192.168.1.10), and one rfc822 name. The public key is an RSA 2048-bit modulus (bit length read from the INTEGER after stripping DER's leading zero byte) with exponent 65537, and both signature algorithm OIDs decode to sha256WithRSAEncryption (1.2.840.113549.1.1.11). The tree view underneath is the same certificate at the byte level — every node with its offset, header hex, tag, and length.
| OID | Name | Where You See It |
|---|---|---|
1.2.840.113549.1.1.1 | rsaEncryption | Public key algorithm for RSA certs and keys |
1.2.840.113549.1.1.11 | sha256WithRSAEncryption | Signature algorithm on most TLS certs today |
1.2.840.113549.1.1.12 / .13 | sha384/sha512WithRSAEncryption | Stronger RSA signatures |
1.2.840.10045.2.1 | id-ecPublicKey | ECDSA public keys |
1.2.840.10045.4.3.2 / .3 / .4 | ecdsa-with-SHA256/384/512 | ECDSA signature algorithms |
1.3.101.112 | Ed25519 | Ed25519 signatures and keys |
1.2.840.10045.3.1.7 | prime256v1 (P-256) | The default EC curve |
1.3.132.0.34 / 1.3.132.0.35 | P-384 / P-521 | Larger NIST curves |
2.5.4.3 / 2.5.4.10 / 2.5.4.6 | commonName / organization / country | Subject and issuer name components |
2.5.29.17 | subjectAltName | The SANs browsers actually validate |
2.5.29.19 | basicConstraints | CA:TRUE/FALSE and path length |
2.5.29.15 / 2.5.29.37 | keyUsage / extKeyUsage | What the key may be used for |
Paste the block starting with -----BEGIN CERTIFICATE----- into the decoder. A PEM file is just base64-encoded DER bytes, so the decoder reconstitutes the DER and walks it as an ASN.1 tree — sequence, integers, OIDs, times — while pulling out the fields people actually want: subject and issuer, serial number, validity dates, SANs, key type and size, and the signature algorithm. Nothing is uploaded; the parsing happens in your browser.
ASN.1 is the notation X.509 is written in: tagged values (integers, OID-named algorithms, sequences) that nest. DER is a strict set of encoding rules for ASN.1 — every value gets a tag byte, a length, and the content bytes. PEM takes those DER bytes, base64-encodes them, and wraps them in BEGIN/END lines so they survive email and copy-paste. Same data, three layers of clothing.
Decode it and read the notAfter field in the Validity section — every certificate carries both notBefore and notAfter as explicit dates in UTC. The decoder also computes days remaining against today's date. Industry practice is to renew at about two-thirds of the lifetime; for a 90-day Let's Encrypt certificate that means kicking off renewal around day 60, which is exactly what auto-renewing clients like certbot schedule.
2048 bits is the accepted minimum everywhere and what most certificates issued today use; 3072 is common for longer-lived or higher-assurance certs, and 4096 is fine but slower to handshake with no security benefit most sites need. Anything at 1024 bits or below is deprecated and rejected by modern browsers and CAs. ECDSA keys (P-256, P-384) are the modern default — equivalent security at a fraction of the size.
It parses the structure of any PEM block — RSA PRIVATE KEY (PKCS#1), EC PRIVATE KEY (SEC1), PRIVATE KEY (PKCS#8), and ENCRYPTED PRIVATE KEY — showing the ASN.1 tree and public components like the RSA modulus and exponent. It never displays the private exponent in a copyable form and nothing leaves the page. If the key is encrypted, it says so and stops; it does not attempt decryption.