Category: Cryptography and Encryption
Format-Preserving Encryption
Also known as: FPE, FF1, FF3
Simply put
Format-preserving encryption (FPE) is a way of encrypting data so that the scrambled output keeps the same format as the original input, such as a 16-digit card number producing another 16-digit number. This lets encrypted values fit into existing systems, forms, and databases that expect a specific structure, without changing field lengths or character types. FPE protects the confidentiality of the data while leaving its shape recognizable to downstream applications.
Formal definition
Format-preserving encryption is a symmetric encryption technique in which the ciphertext conforms to the same format and domain (for example, alphabet, length, or character set) as the plaintext. NIST SP 800-38G specifies the FF1 and FF3 (later FF3-1) block-cipher modes as approved FPE methods. As a cryptographic confidentiality control, FPE belongs to information security rather than data governance; it does not by itself address data ownership, lineage, or retention. Critically, FPE is a reversible transformation keyed by a secret, so encrypted values remain re-identifiable and therefore should generally be treated as personal data (not anonymized) where the source data is personal; applying FPE does not remove data from the scope of most data protection regimes. This entry defines the concept and its cryptographic function only; it does not cover key management practices, applicable lawful bases for processing, cross-border transfer requirements, or the distinction between FPE and vendor-specific tokenization implementations, some of which market FPE under the term tokenization despite differing security properties.
Why it matters
Format-preserving encryption addresses a practical constraint that conventional encryption often cannot: legacy systems, databases, and application forms frequently expect a specific field format, such as a fixed-length numeric string. Because standard block-cipher output changes both the length and character set of a value, retrofitting encryption into these systems can require costly schema changes. FPE lets organizations protect the confidentiality of structured data, such as account or card numbers, while keeping the ciphertext in the same shape the downstream system expects, reducing integration friction.
Who it's relevant to
Privacy engineers and data protection officers
FPE is a reversible, keyed transformation, so encrypted values remain re-identifiable to any party with the key. Where the source data is personal data, FPE-protected data should generally still be treated as personal data and remains within the scope of most data protection regimes. Applying FPE does not anonymize data and should not be mistaken for a technique that removes data from regulatory scope.
Security architects and engineering teams
FPE is a cryptographic confidentiality control belonging to information security rather than data governance. It is particularly useful when encryption must be introduced into systems that enforce specific field formats, since it avoids changes to field lengths or character types. Teams should note that this entry covers the cryptographic function only and does not address key management practices, which are essential to the security of any FPE deployment.
Procurement and vendor management
Some vendors market FPE under the label tokenization, and the two are sometimes conflated despite differing security properties. When evaluating products, verify whether an offering implements NIST-approved FPE methods such as FF1 or FF3-1, or a vendor-specific tokenization scheme, since these are not interchangeable. This entry does not compare FPE against specific tokenization implementations.
Compliance and governance leads
FPE addresses confidentiality but does not by itself address data ownership, lineage, or retention, which fall under data governance. It also does not establish a lawful basis for processing, satisfy cross-border transfer requirements, or determine retention rules. Treat FPE as one control within a broader governance and compliance program rather than as a compliance outcome in itself.
Inside FPE
Format-Preserving Encryption (FPE)
A form of encryption in which the ciphertext output retains the same format, length, and character set as the plaintext input. For example, a 16-digit card number encrypts to another 16-digit numeric string. This allows encrypted values to fit within existing database schemas, field validation rules, and downstream systems without structural changes.
Format preservation
The defining property that the output conforms to a specified domain or format constraint (such as numeric-only, fixed length, or a particular character set) rather than producing arbitrary binary ciphertext. This is what distinguishes FPE from conventional block or stream encryption.
Reversibility
FPE is a reversible cryptographic transformation: with the correct key, the original plaintext can be recovered. Because the underlying values remain recoverable, data protected by FPE generally continues to be personal data where the source values are personal data.
Key and algorithm dependency
The security of FPE depends on the strength of the algorithm, the key length, and the key management practices applied, in the same way as other symmetric encryption. The format constraint does not remove the need for robust key generation, storage, rotation, and access control.
Relationship to tokenization
FPE is sometimes used to implement tokenization-style substitution where format compatibility is required. Unlike some tokenization approaches that use lookup tables, FPE derives the substitute value cryptographically from the plaintext and key.
Common questions
Answers to the questions practitioners most commonly ask about FPE.
Does applying format-preserving encryption to a data field make that data no longer personal data?
No. Format-preserving encryption is a reversible protection measure, not anonymization. Because the original values can be recovered with the key, the data remains personal data (and potentially special category data) and stays within the scope of applicable regimes such as the EU GDPR and UK GDPR. At most, it may support a pseudonymization argument, but pseudonymized data is still regulated personal data. Encryption or tokenization does not remove data from scope.
Is format-preserving encryption the same as tokenization since both can preserve field length and format?
They are distinct techniques even though both can produce output that matches the original format. Format-preserving encryption is a cryptographic transformation governed by a key, so recovery depends on the key and algorithm. Tokenization typically substitutes a value using a lookup mapping (a token vault) rather than a reversible cipher over the data itself. This entry does not resolve which approach a given deployment should choose; that depends on architecture, key management, and threat model. Neither technique, on its own, renders data non-personal.
Where does format-preserving encryption typically fit within a data protection program?
It is generally positioned as a technical security control that protects the confidentiality of structured data while allowing systems that expect a specific format to continue functioning. It sits within the information security domain (confidentiality and, where implemented well, integrity) and may contribute evidence toward a pseudonymization strategy. It does not by itself address governance concerns such as data ownership, lineage, retention, or lawful basis, which must be handled separately.
How does using format-preserving encryption affect obligations around lawful basis and records of processing?
Applying format-preserving encryption does not change the lawful basis required for processing, nor does it remove the need to document processing activities where such an obligation applies. The encrypted values still represent personal data being processed, so the underlying purpose, lawful basis, retention, and disclosure considerations remain. This entry does not cover how to determine a lawful basis or the mechanics of any records-of-processing requirement.
Does deploying format-preserving encryption require a data protection impact assessment?
Not automatically. Whether a data protection impact assessment is needed depends on the nature, scope, context, and risk of the processing under the applicable regime, not on the presence of a specific control. Format-preserving encryption may be one of the risk-mitigation measures documented within an assessment, but its use neither triggers nor waives the assessment obligation. Consult the relevant regime and internal criteria to determine whether an assessment is required.
What implementation limitations should teams weigh when relying on format-preserving encryption?
Because the technique is reversible, its protective value depends heavily on key management, access controls, and the surrounding security architecture, which are out of scope for this definition. Teams should also consider that preserving format may retain patterns or field structure that could aid inference, and that reversibility means the data remains personal data with continuing regulatory obligations. This entry does not address cross-border transfer mechanics, retention rules, algorithm selection, or enforcement consequences.
Common misconceptions
Applying format-preserving encryption makes the data non-personal and takes it outside the scope of data protection law.
FPE is reversible with the key, so the underlying values remain recoverable. Encryption or tokenization does not render data non-personal. In most jurisdictions, including under the EU GDPR and UK GDPR framing, such data is generally treated as pseudonymized personal data that remains in scope, not as anonymized data.
Format-preserving encryption is the same as anonymization because the visible value looks different.
Anonymization is intended to be irreversible and to place data outside most regulatory scope. FPE is reversible by design and is closer to pseudonymization, which remains subject to data protection obligations. The two should not be treated as interchangeable.
Because it preserves format and looks like conventional encryption, FPE guarantees compliance for handling sensitive fields such as payment or identifier data.
No single control guarantees compliance. FPE can be a useful technical safeguard, but compliance depends on context, jurisdiction, key management, applicable standards, and the wider control environment. FPE alone does not satisfy retention, lawful basis, or transfer requirements.
Best practices
Continue to treat FPE-protected values as personal data where the source values are personal, and reflect this in records of processing, access controls, and retention decisions rather than assuming the data is out of scope.
Implement strong key management, including controlled key generation, secure storage separate from the protected data, defined rotation, and restricted access, since the reversibility of FPE means the key is the primary point of exposure.
Document why FPE was selected over alternatives such as full-strength conventional encryption or irreversible techniques, and record the format and domain constraints applied, so the control is demonstrable as accountability evidence rather than merely stated intent.
Do not rely on FPE as a standalone compliance measure; combine it with governance controls covering ownership, access policy, and monitoring, and with security controls addressing confidentiality, integrity, and availability.
Assess whether the chosen FPE approach and its parameters align with any applicable standards or scheme requirements relevant to the data type in question, and confirm that treatment expectations may differ across jurisdictions and regimes.
Verify that downstream systems handling the format-preserved output do not inadvertently expose the underlying values or the recovery path, and restrict decryption capability to the minimum necessary roles.