Where your data goes

	Using this page	Using the API, MCP or A2A
Where it runs	In your browser. Decoding and signature checks run in the page with `@peculiar/x509` and Web Crypto. The page makes no network requests, so it never contacts OCSP responders, CRL servers or the certificate's issuer URLs.	In a Cloudflare Pages Function at the Cloudflare data centre nearest the caller.
What leaves your device	Nothing you enter. After the page and its scripts load, no request carries your input. The browser enforces this: the page's Content-Security-Policy sets `connect-src 'none'` and `form-action 'none'`, which block fetch, XHR, WebSocket, EventSource, beacons and form posts.	The server receives the certificate data, decodes it in memory, and returns the decoded fields. Certificates and CSRs are public by design, but the input is not stored or logged (only the per-call metadata row is recorded). The server makes no network requests (it does not fetch OCSP, CRLs or issuer certificates). Private keys in the input are rejected.
Stored	Nothing leaves the page. No cookies, analytics or third-party scripts; the browser keeps only your View → Inline config choice.	Your inputs and results: never. What is stored is your client record (client ID, a SHA-256 hash of your secret, expiry, and the profile you registered with) and one metadata row per call: operation, time, transport, status, error code, duration, request and response sizes, and country.
Logged	Nothing (no requests are made).	Only the per-call metadata above, attributed to your client ID. Never parameters, bodies, results, or credentials. Cloudflare, as the host, also processes request metadata (IP address, full URL including the query string, headers) under its own policies, so put inputs in POST bodies.
Access	Open to anyone.	Requires a client ID and secret (how to get one). HTTPS only; TLS terminates at Cloudflare.

Details and how to verify this yourself: Security & privacy.

User guide

The tool sits in a window that works like a desktop app: menus on the top row and the full-screen icon at its right (Esc leaves full screen). The set-up options described below are in Settings → Options…, an overlay, and the Settings menu also lists the common choices directly. To keep the options in view instead, choose View → Inline config; the page remembers that choice. Help → Keyboard shortcuts… lists the keys.

Paste one or more PEM blocks, or open a file: .pem, .crt, .cer, binary .der, a .p7b bundle, or a .csr.
Optionally enter a host name to check whether the certificate covers it.
Read the cards. There is one per certificate, labelled Leaf, Intermediate CA or Root (self-signed), plus one per CSR.

Checking a server’s chain. Paste the chain in the order the server sends it, leaf first. The summary tells you whether each certificate is signed by the next one, flags gaps or wrong order, and notes expired certificates. A typical healthy server chain is leaf → intermediate, without the root.

Getting a server’s chain (on your own machine):

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Paste everything between and including the BEGIN/END CERTIFICATE lines.

Checking a CSR before sending it to a CA. Paste the CERTIFICATE REQUEST. Confirm the subject, the SANs and the key type. Signature valid proves the request was made by whoever holds the matching private key.

What this does not tell you. A chain that “looks correct” here is structurally sound. Whether it is trusted depends on the client’s root store, and whether it has been revoked depends on OCSP/CRL. This tool checks neither. Use your browser, openssl verify -CAfile …, or an online TLS scanner for those.

Specification

Input.

PEM labels: CERTIFICATE, X509 CERTIFICATE, PKCS7, CERTIFICATE REQUEST and NEW CERTIFICATE REQUEST, in any number and order.
Other forms: raw DER (from a file), or Base64 DER pasted without armor.
Private keys: input containing any PRIVATE KEY block is rejected.

Certificate fields.

Field	Source
Subject, issuer	RFC 4514 string form of the distinguished names
Validity	`notBefore`/`notAfter`. Status (valid, expired, not yet valid) and whole days remaining are evaluated at the current time (the API’s `at` parameter overrides it)
Subject alternative names	DNS, IP, email, URI, directory name and other GeneralName types
Public key	Algorithm, size (RSA modulus bits or curve), RFC 7469 SPKI pin
Signature	Algorithm and hash, e.g. RSA PKCS#1 v1.5 with SHA-256, ECDSA with SHA-384, Ed25519
Key usage / extended key usage	RFC 5280 §4.2.1.3 / §4.2.1.12, with common purposes named
Basic constraints	CA flag and path length
Policies	OIDs, with CA/Browser Forum DV/OV/IV/EV policies named
AIA, CRL distribution points	OCSP and CA-issuer URLs; CRL URLs (shown, never fetched)
SCTs	Whether Certificate Transparency SCTs are embedded (OID 1.3.6.1.4.1.11129.2.4.2)
Fingerprints	SHA-256 and SHA-1 over the DER

Chain checks. For each adjacent pair (certificate n, certificate n+1):

The issuer name of n must equal the subject name of n+1, compared as the RFC 4514 string.
The signature on n must verify with the public key of n+1, using Web Crypto.

The last certificate is reported as a root if it is self-signed: its subject equals its issuer and it verifies with its own key.

Host-name check.

Rules: RFC 6125 §6.4. Case-insensitive; a wildcard is allowed only as the entire left-most label and matches exactly one label (*.example.com matches a.example.com, but not example.com or a.b.example.com).
Names checked: only DNS SANs. The subject CN is ignored, as modern clients do.

CSRs (RFC 2986). The decoder reports the subject, the requested SANs (from the extensionRequest attribute), the public key, and whether the self-signature verifies.

Not performed. Trust-anchor validation, revocation checking, name constraints, policy processing, and Certificate Transparency log lookups.

API & MCP

The same logic is available over HTTP and as MCP tools. Unlike this page, these run on the server: see where your data goes.

GET POST /api/cert/decode Decode X.509 certificates, chains, and certificate requests. MCP tool cert_decode · 4 parameters · full reference →

Certificate Decoder