{{ summaryHeading }}
{{ summaryFigure }}
{{ summaryLine }}
{{ badge.text }}
{{ lane.label }}
PEM block extraction input
Paste one bundle or drop a .pem, .crt, .cer, .csr, .key, .pub, or .txt file.
Drop one PEM, CRT, CER, CSR, KEY, PUB, or TXT bundle onto the textarea.
Use letters, numbers, dots, underscores, or hyphens; blank keeps names like cert_01.crt.
{{ normalizedHashPreviewChars }} chars
Choose 8, 12, 16, 20, 24, 28, or 32 displayed SHA-256 characters.
# Type Lines Block details Download Copy
{{ b.idx }} {{ b.type }} {{ b.lineSpan }}
{{ b.summary }}
{{ formatNumber(b.byteLength) }} bytes · SHA-256 {{ b.sha256Prefix }} · {{ b.filename }}
No PEM blocks found.
Block type Count First # Last # Total bytes Copy
{{ row.type }} {{ row.count }} {{ row.firstIdx }} {{ row.lastIdx }} {{ formatNumber(row.totalBytes) }}
No block coverage data available.
# Stage Status Detail Evidence Copy
{{ row.idx }} {{ row.stage }} {{ row.status }} {{ row.detail }} {{ row.evidence }}
No extraction trace available.

                
Customize
Advanced
:

Certificate work often leaves several text-wrapped objects pasted into one place: a server certificate, one or more intermediate certificates, a certificate signing request, a public key, or a private key. The wrapper is the part that makes the text recognizable. Each object starts with a line such as -----BEGIN CERTIFICATE----- and ends with a matching -----END CERTIFICATE----- line. When those boundaries are copied into a ticket, configuration note, secret store, or proxy setting, the labels are usually the only dependable separators.

PEM is not one single object type. It is a text envelope used for several Public Key Infrastructure (PKI) and cryptographic formats. The body is normally base64 text that represents a binary structure such as an X.509 certificate or a PKCS #10 certificate signing request (CSR). The label tells a reader what the body is supposed to contain, but the label alone does not prove the object is valid, trusted, current, or paired with the right key.

Certificate
A signed identity document with subject, issuer, validity dates, and a public key.
Certificate chain
Several certificates kept in order so a server certificate can be linked toward a trusted issuer.
CSR
A request sent to a certificate authority, signed with the requester's private key.
Private key
Secret key material that must be protected even when it is only being copied for inspection.
Flow from copied PEM text to matching boundary pairs and split-item evidence

Clean extraction is mostly an evidence problem. A copied bundle may include comments, blank lines, repeated certificates, old CSRs, or an accidental private key left from a renewal step. Preserving source order and line spans lets you split the text without guessing where one object ended. Recording byte counts and digest prefixes gives you a way to compare two extracted items that look almost the same in a long monospace block.

The important limit is that splitting PEM text is not the same as validating PKI. A complete boundary pair can still contain an expired certificate, a CSR for the wrong name, a public key that does not match a certificate, or an encrypted private key that cannot be opened with the passphrase you expect. Extraction should come before those format-specific checks, not replace them.

How to Use This Tool:

Use the full copied value whenever possible. The count, line spans, and trace are most useful when the original order is still intact.

  1. Paste the text into PEM bundle, drop a .pem, .crt, .cer, .csr, .key, .pub, or .txt file onto the field, or choose Browse PEM file. Results update after the text changes.
  2. Check the summary before working row by row. It shows the recovered PEM block count, scanned line count, recovered type count, and badges for certificates, CSRs, keys, other labels, and the source SHA-256 prefix.
  3. Open Advanced only if exported filenames need a prefix or the visible fingerprint prefix should be longer. Filename prefix changes generated names, while Fingerprint preview changes display length only.
  4. Use Block Inventory to inspect each recovered object. The Type, Lines, Block details, filename, byte count, and SHA-256 prefix give you the evidence needed before copying or downloading a block.
  5. Use Type Coverage for a bundle-level check. It is the fastest place to confirm counts such as three CERTIFICATE blocks, one PRIVATE KEY, or an unexpected CERTIFICATE REQUEST.
  6. If the page shows No PEM blocks found, No complete PEM block pairs were found, or a warning in Extraction Trace, return to the source text and copy complete matching BEGIN and END lines instead of editing labels by guesswork.
  7. Use JSON when you need a machine-readable record of the input metadata, coverage rows, block summaries, and extraction trace.

Interpreting Results:

Start with the recovered block count. If the count is lower than expected, treat the row details as incomplete until Extraction Trace explains the mismatch. A common sign of a bad paste is a BEGIN marker count that does not match the number of complete pairs.

Block Inventory is strongest for item-level evidence. Lines preserves where the block appeared in the original text, the byte count catches unusually short or long objects, and the SHA-256 prefix helps distinguish copied blocks that share similar labels and subject names. A matching prefix only compares the recovered text handled by the page; it is not a DER certificate fingerprint.

Type Coverage is strongest for cleanup decisions. A certificate chain should usually have certificate rows, while a renewal note might also contain a CSR or key. An unexpected key row deserves extra care because private keys are sensitive even when the extraction itself succeeds.

Do not read a parsed summary as a trust verdict. A certificate row with a common name and expiry date still needs chain, hostname, and revocation checks when those matter. A CSR marked Verified means its request signature verifies against its embedded public key; it does not mean a certificate authority will accept it. An encrypted-key label does not test a passphrase.

Technical Details:

RFC 7468 describes the common textual encoding used for PKIX, PKCS, and CMS structures. The envelope starts with five hyphens, the word BEGIN, one space, a label, and five closing hyphens. It ends with the same form using END. The encoded body normally represents ASN.1 data such as an X.509 certificate or PKCS #10 CSR that would otherwise be handled as DER bytes.

For extraction, boundary matching is the first rule. A complete item requires a starting boundary and an ending boundary with the same label. Text outside those pairs may be useful context for a person, but it is not a recovered PEM object. The scan keeps complete pairs in source order, records line spans from the original text, and leaves incomplete or mismatched material out of the recovered list.

Transformation Core

PEM extraction stages and visible evidence
Stage Rule Visible evidence
Input scan Trim the supplied text, count lines and characters, and count BEGIN markers. Summary line, source SHA-256 prefix, and an extraction trace entry showing scan scope.
Boundary pairing Recover only text that has matching BEGIN and END labels. Recovered block count, Lines, and consistency warning when markers and pairs differ.
Label classification Group exact certificate labels, CSR labels, key labels, and other PEM labels. Summary badges and Type Coverage rows.
Detail parsing Try to read certificate, CSR, and RSA key fields when the recovered type supports it. Block details such as common name, issuer, expiry date, RSA size, or CSR verification status.
Evidence output Attach a safe filename, byte count, and SHA-256 digest prefix to each recovered item. Inventory rows, coverage rows, downloaded split files, copied rows, and JSON.

The label decides the first classification. CERTIFICATE is treated as an X.509 certificate candidate. A label containing CERTIFICATE REQUEST is treated as a CSR candidate. Labels containing PRIVATE KEY or PUBLIC KEY are treated as key material. Other matching labels are preserved rather than discarded, because PEM wrappers are also used for structures such as PKCS #7.

PEM labels, groups, summaries, and filename shapes
Recovered label Group Summary attempt Filename shape
CERTIFICATE Certificate Subject common name, issuer common name, NotAfter date, and RSA size when readable. cert_XX.crt
Contains CERTIFICATE REQUEST CSR Subject common name and Verified or Not verified. csr_XX.csr
Contains PRIVATE KEY or PUBLIC KEY Key Private, public, or encrypted key label plus RSA size when readable. key_XX.key
Contains PKCS7 Other Label and byte count. bundle_XX.p7b
Any other matching label Other Label and byte count. pem_XX.pem

A CSR signature check has a narrow meaning. PKCS #10 requests contain a subject, public key, optional attributes, and a signature made by the requester. When the summary says Verified, it means that signature checks against the public key inside the CSR. It does not check certificate authority policy, domain control, subject alternative names, or whether the private key is still available.

SHA-256 prefixes are used here as change-detection evidence for handled text. The source prefix identifies the full trimmed input, while each row prefix identifies the recovered PEM text for that row. Because textual PEM can vary in whitespace and wrapping, that digest should not be confused with a certificate fingerprint calculated over canonical DER bytes.

A useful end-to-end check is a copied renewal note with two CERTIFICATE blocks, one ENCRYPTED PRIVATE KEY, and one CERTIFICATE REQUEST. The scan should find four complete pairs, group them as two certificates, one key, and one CSR, preserve their original row order in Block Inventory, and show the first and last positions for each label in Type Coverage. If the CSR's ending label is missing, the marker count and complete pair count will diverge and the incomplete request will not become a recovered row.

Privacy Notes:

Selected files and pasted text are read in the browser, and extraction does not require uploading PEM contents for server-side parsing. The sensitive part is what happens around the browser session.

  • Form values can be reflected in the page URL, so avoid sharing a URL after pasting private keys, internal certificates, or production CSRs.
  • Copied rows, downloaded blocks, CSV files, DOCX files, and JSON exports should be protected like the original material.
  • If you only need to test the workflow, use sample PEM text instead of live production key material.

Worked Examples:

Proxy certificate chain

A reverse proxy export contains three consecutive CERTIFICATE blocks. The summary should show 3 PEM blocks, Type Coverage should show CERTIFICATE with Count 3, and Block Inventory should keep rows 1, 2, and 3 in the source order. Use the Lines values before saving separate files so the chain order is not accidentally reversed.

Renewal note with leftover request text

A renewal ticket includes two CERTIFICATE blocks, one ENCRYPTED PRIVATE KEY, and one CERTIFICATE REQUEST. The badges should show certificates, keys, and CSRs separately, while Type Coverage confirms the counts. If the CSR row says Verified, treat that as evidence about the request signature only; it does not mean the CSR should be resubmitted.

Pasted key with a missing ending line

A copied private key starts with -----BEGIN PRIVATE KEY----- but the final ending line was left behind. The page reports No complete PEM block pairs were found, or Extraction Trace warns that marker and pair counts differ when other complete blocks are present. Copy the key again from the source rather than inventing an ending label, because the missing text may include more than the boundary line.

FAQ:

Does it decrypt encrypted private keys?

No. It can identify key text that appears encrypted from the wrapper or legacy header, but it does not request a passphrase or test whether the private key can be opened.

Can it prove a certificate and private key match?

No. It separates and summarizes PEM blocks. Use a certificate/key match check after extraction if you need to prove that a private key belongs with a certificate.

Why did a block appear as Other?

The recovered boundary label did not match the certificate, CSR, private-key, or public-key grouping rules. The block is still preserved so you can inspect it with a format-specific workflow.

Why are two similar certificates showing different SHA-256 prefixes?

The prefix is based on the recovered PEM text. Different wrapping, spacing, or copied text can change that text digest even when a DER-level certificate comparison may tell a different story.

What should I check when no PEM blocks are found?

Confirm that the input includes complete BEGIN and END boundary lines. If the markers are absent, the text is not PEM or the source copy removed the wrapper.

Glossary:

PEM
A text envelope for base64-encoded cryptographic structures with labeled BEGIN and END boundaries.
Boundary label
The label between the BEGIN or END word and the trailing hyphens, such as CERTIFICATE or PRIVATE KEY.
CSR
A certificate signing request that carries a subject, public key, optional attributes, and a request signature.
DER
A binary Distinguished Encoding Rules representation commonly used inside certificates and requests before text wrapping.
Certificate chain
An ordered set of certificates used to connect a server certificate toward an issuer trusted by the relying system.
SHA-256 digest
A fixed-length hash used here to identify whether handled text changed between copies.
Line span
The starting and ending line numbers where a recovered PEM block appeared in the original text.

References: