Three containers for one certificate
Every X.509 certificate is a DER-encoded ASN.1 structure. A .der file, and often a .cer file on Windows, is those bytes and nothing else. PEM takes the same bytes, encodes them in Base64 at 64 characters per line, and puts -----BEGIN CERTIFICATE----- above and -----END CERTIFICATE----- below. Because PEM is text, several certificates can sit one after another in a single file.
PKCS#7, with the extensions .p7b and .p7c, is a signed-data container used here with no signature at all: a list of certificates and nothing more. It has a binary form and a PEM form that begins -----BEGIN PKCS7-----. None of the three formats holds a private key. That belongs to PKCS#12, the .pfx or .p12 file, which is a separate, encrypted container.
How the input is recognised
The converter looks at content, never at the file name. A file with a BEGIN line is read as PEM and each block is handled by its label. Anything else is parsed as binary and classified by its ASN.1 structure as a certificate, a PKCS#7 bundle, a PKCS#12 file, a CSR or a private key. That is the safe approach, because .crt and .cer are used for both text and binary files.
Above the table, one line reports what was found, for example 3 certificates, chain.pem: PEM (3 blocks), or DER (PKCS#7 / .p7b) for a binary bundle. Each row shows the subject common name (the organisation when there is none), the issuer and the expiry date, with an expired tag on certificates past their date. The paste box needs the BEGIN and END lines around the Base64.
Which output to give which server
The download buttons write the whole list to one file, except DER, which by its nature holds a single certificate. Files are named after the first certificate's common name. Pick the format from what the receiving software asks for, not from the extension it happens to mention.
The PEM output box shows the bundle as text with a Copy PEM button, for control panels that have a paste field instead of a file upload. Copy Base64 gives the first certificate as one line with no header, the form that environment variables and JSON configuration expect.
- PEM bundle: Apache, Nginx and most Linux software
- DER (.cer): Java and Windows, one certificate per file
- PKCS#7 (.p7b): Windows, IIS and Java keystore imports of a full chain
- PKCS#7 PEM: the same chain as text, starting with BEGIN PKCS7
Building and splitting a chain bundle
To build a bundle, paste the server certificate followed by its intermediates and press Convert pasted text. The output keeps the order you gave. Nothing is sorted or removed. Order matters to servers: Nginx, for example, expects the server certificate first in the file named by ssl_certificate, with the intermediates after it. Leave the root out unless your software asks for it.
To split a bundle, upload it and use the PEM or DER links in each row to save the certificates separately. That is the usual fix when a CA delivers a single .p7b and the server wants separate certificate and chain files. Open the result in the certificate decoder to confirm that each Issuer matches the Subject of the certificate after it.
What the converter leaves alone
Certificates are the only objects it converts. A PFX or P12 upload produces a notice with the command openssl pkcs12 -in file.pfx -out bundle.pem -nodes, which asks for the password and writes the certificates and the unencrypted key to one PEM file. Going the other way needs the key as well: openssl pkcs12 -export -out site.pfx -inkey private.key -in cert.pem -certfile chain.pem.
A CSR in the input is reported and skipped, a private key is ignored, and unknown blocks are listed as skipped. The tool does not check that the certificates form a valid chain, that they match your key, or that a browser would trust them. If you need a new key and request, start from the CSR generator.