Use an email verification code to access your account securely.
SSL / TLS / X.509 inspection
Decode and inspect public SSL/TLS, PEM, and X.509 certificate data in your browser.
Browser-based inspection
Your certificate is processed in your browser and is not uploaded or stored.
Decoded certificate
A certificate decoder reads the structured data inside an SSL/TLS or X.509 certificate and presents it in a form that is easier to inspect. A certificate is the public document a server uses to identify a domain and establish encrypted connections. It does not replace certificate validation performed by a browser or server, but it makes the encoded fields easier to review during troubleshooting, deployment, and renewal work.
Typical certificate data includes the subject, issuer, validity period, subject alternative names, serial number, public key, signature algorithm, extensions, and one or more fingerprints. Reviewing these fields helps explain which domains a certificate covers, which certificate authority issued it, and whether the certificate currently appears valid according to its dates.
For a certificate installed on a live website, compare the decoded result with the hostname you expect to serve. The tool shows the certificate that you provide; it does not connect to a domain and silently replace the input with a remote result. This makes the workflow useful for checking downloaded files, deployment artifacts, and copied server configuration.
The results include the overall certificate status, validity dates, days remaining, subject, common name, organization, issuer, and subject alternative names. They also expose the serial number, X.509 version, signature algorithm, public key algorithm, key size where available, extensions, and SHA-256 and SHA-1 fingerprints.
The subject alternative name list is especially important for modern HTTPS. Browsers generally use SAN entries when deciding whether a certificate matches a hostname. A common name alone may not be enough to explain a hostname warning, so check every relevant DNS name in the decoded output.
Fingerprints identify the exact certificate bytes. SHA-256 is the preferred comparison value for most operational checks. A fingerprint comparison can reveal that a certificate changed even when the visible domain names and issuing authority stayed the same.
This tool accepts PEM certificate data and PEM certificates saved with .pem, .crt, or .cer file extensions. The file extension is only a label: the content must contain a public certificate block. A CRT or CER file in binary DER form will not be treated as PEM text by this page.
PKCS#7 files such as P7B, PKCS#12 bundles such as PFX or P12, certificate signing requests, and private-key files are outside the supported input boundary. Export the public certificate as PEM first when your certificate authority or server provides another container format. Do not convert or upload a private key just to inspect a public certificate.
Review the Not Before and Not After fields. Not Before is the beginning of the certificate's validity window, while Not After is the expiration date. The remaining-days value is calculated from the current time and the Not After date, so it is a quick operational signal rather than a replacement for your certificate monitoring system.
A certificate may be valid, expiring soon, expired, or not yet valid. An expired certificate can still contain correct domain names and issuer information, but browsers will reject it for normal HTTPS use. A not-yet-valid certificate can indicate an incorrect system clock, a deployment scheduled for later, or a certificate that was issued with an unexpected start date.
Save the old and new public certificates, then compare their serial numbers, SHA-256 fingerprints, validity periods, issuer, signature algorithm, and SAN entries. A changed serial number or fingerprint is a direct signal that the certificate bytes are different. A changed Not After date may show renewal even when the rest of the identity information remains similar.
After installing a replacement, obtain the certificate from the same deployment path that clients use and decode that copy as well. Check the edge proxy, load balancer, web server, and any separate staging hostname if your traffic can reach more than one endpoint. Different endpoints serving different certificates are a deployment issue, not a parsing issue.
A public certificate is intended to be distributed and normally contains no private key. Even so, treat certificate material carefully and use a trusted tool. This page processes certificate text and files in your browser and does not upload or store them for decoding. You can also use a local command-line tool when your policy requires all inspection to stay on a managed workstation.
Never paste a private key, password, PFX/P12 bundle, or other secret into this page. A private key can allow an attacker to impersonate a service or decrypt traffic in scenarios where the key is usable. If a file contains both a certificate and a private key, separate the public certificate before inspection and keep the secret in its protected storage.
It is a tool that reads and displays the public fields inside an SSL/TLS or X.509 certificate.
Paste the complete PEM block into the input area and click Decode Certificate.
Yes. Paste a PEM-encoded X.509 certificate into this browser-based decoder.
Decode the certificate and review the Not After, Valid Until, and Days Remaining values.
A fingerprint is a digest of the certificate bytes. SHA-256 is commonly used to identify the exact certificate.
No. A public certificate contains a public key. Never paste a private key into an online tool.
Compare its serial number, fingerprints, issuer, SANs, and validity period with the previous certificate.
No. This tool processes the certificate in your browser and does not upload or store it.