Decode a PKCS#10 Certificate Signing Request (CSR) to verify its subject, public-key algorithm, and signature before you submit it to a CA.
A Certificate Signing Request (CSR) is a PKCS#10 message you send to a certificate authority to request a certificate. It contains the subject name you are asking for, your public key, and a self-signature proving you hold the matching private key. Like a certificate it is DER-encoded ASN.1, usually in Base64 PEM armor (-----BEGIN CERTIFICATE REQUEST-----). This decoder unwraps it and shows the subject, public-key algorithm, and signature algorithm so you can verify the request is correct before you submit it — a mistake caught here saves a re-issue later. It all runs in your browser; nothing is uploaded.
Why check a CSR first. The CA copies fields from your CSR into the issued certificate, so a typo in the subject, the wrong Common Name, or a missing attribute becomes a wrong certificate you then have to reissue. Decoding the CSR lets you confirm the subject (organization, Common Name) and the key details match what you intend to deploy.
What the fields mean. The subject is the identity you are requesting — typically a Common Name (the hostname) plus organization details. The public-key algorithm (e.g. rsaEncryption or ecPublicKey) is the type of key that will be certified. The signature algorithm is how the CSR was self-signed. Some CSRs also carry requested extensions such as SANs inside an attributes section; the ASN.1 tree view lets you inspect those directly.
Scope — read this. This is a best-effort structural decoder. It parses the DER/ASN.1 and extracts the standard CSR fields, and prints the full ASN.1 tree for anything not summarized. It does not cryptographically verify the CSR's self-signature or confirm the key size beyond what the structure reveals; use openssl req -verify for signature verification.
How you'll use it. Generate a CSR with openssl req -new, then paste it here to confirm the subject and key before handing it to your CA. It is also handy when troubleshooting a rejected request — decoding shows exactly what you sent.
Common mistakes it helps catch. A Common Name that does not match the hostname you will serve, a missing organization field a CA requires, or a weaker-than-intended key/signature algorithm. Catching these pre-submission avoids a wasted issuance cycle.
Defensive angle. Generate CSRs with strong keys (RSA-2048+ or ECDSA P-256+), keep the private key on the machine that generated it and never paste it into any tool, and prefer automated issuance (ACME) where possible so human transcription errors are eliminated entirely. Once the CA returns your certificate, run it through the certificate decoder to confirm the issued subject, SANs, and validity window match the request you sent.
Caesar, ROT13, Atbash, and Vigenère transforms plus letter-frequency analysis for CTF and puzzle solving.
Shannon entropy and character-class analysis for a secret.
Compute MD5, SHA-1, SHA-256, and SHA-512 digests of any text in one pass, entirely in your browser.
Identify likely hash algorithms from a digest by its length, character set, and prefix format.
Generate keyed HMAC signatures (HMAC-SHA1, HMAC-SHA256, HMAC-SHA512) for API signing and webhook verification.
Generate strong, cryptographically-random passwords with configurable length and character sets — computed in your browser and never transmitted.