Convert between PKCS#12 (.pfx/.p12) and PEM format certificates and private keys.
Repackages X.509 material between two container styles. It unpacks a password-protected .pfx/.p12 into its separate PEM blocks - a private key, then each certificate in the chain, one block per item - and it does the reverse, bundling a PEM private key with its certificate chain into a password-protected .p12 file. The recurring surprise is that a PKCS#12 file is encrypted, not merely encoded: the password locks the entire container, so without it the conversion cannot even start, and there is no recovery path. A .pfx commonly holds several certificates, so PEM output is usually multiple blocks rather than one.
A concrete input and expected output from the current implementation.
Input
Two PEM blocks pasted one after the other - a private key (-----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY-----) and its matching certificate (-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----) - plus an export passphrase of 'change-it-now'. The base64 bodies are elided here; a real paste includes them in full.
Expected output
A .p12 file delivered as a download, containing exactly one private key and one certificate. Opening it, listing its contents, or converting it again requires the passphrase 'change-it-now'; any other passphrase fails before the contents are visible.
The converter base64-decodes each PEM block to its DER form, packs the two items into the container, and derives the file's encryption and MAC keys from the passphrase you entered, so that passphrase is the only one that can ever open it. The output is binary, so this entry describes its structure rather than bytes, which depend on your key material.
PKCS#12 (RFC 7292) is a binary container: the private key and certificates sit in safe bags inside an encrypted structure checked by a MAC, all locked by a password. PEM (RFC 7468) is the same underlying DER data printed as base64 between label lines such as -----BEGIN CERTIFICATE-----. Converting means decoding one structure and re-encoding the other. The whole conversion runs in the browser page, so the key material never leaves the machine.
When building a .p12, the passphrase you enter becomes the only key to the file: the converter derives the encryption and integrity keys from it, and the whole container is encrypted rather than just labeled. When unpacking, the same derivation must succeed or nothing decrypts. That is why there is no forgot-password flow, and why a strong passphrase matters more than where the file is stored.
None, in practice. Both extensions denote the same PKCS#12 container: .pfx is the older name popularized by Microsoft tooling, and .p12 is the name used in the RFC 7292 specification and by most Unix software. A converter treats them identically, and renaming a file from one to the other changes nothing about its contents.
No. The contents are encrypted and integrity-protected with keys derived from the password, so without it no converter can read the private key. Guessing is practical only for very weak passphrases; otherwise the only routes are re-exporting from the machine that created the file or reissuing the certificate.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.