What Is Format-Preserving Encryption and What Are Its Benefits?

Format-preserving encryption, or FPE, encrypts a value while keeping the ciphertext in the same general format as the plaintext. A 16-digit number can remain 16 digits, and a value drawn from an alphabetic character set can remain alphabetic. This makes FPE useful when applications, databases, and downstream systems cannot accept conventional ciphertext that changes a field’s length or character set.

What is format-preserving encryption?

Conventional encryption commonly produces binary ciphertext that is longer than the original value once nonces, authentication tags, and encoding are included. That output may not fit a legacy database column, fixed-width message, validation rule, or application workflow.

FPE operates over a defined domain, such as decimal strings of a permitted length. The encrypted output stays inside that domain and can be decrypted back to the original value by an authorized operation.

A 9-digit identifier can encrypt to another 9-digit value.
A 16-digit account number can encrypt to another 16-digit value.
An alphanumeric customer code can remain within the same permitted character set.

Preserving syntax does not preserve meaning. An FPE ciphertext that looks like an account number is not necessarily a valid account, and applications should not treat it as one without explicit design and validation rules.

Where FPE helps

FPE is most valuable when changing the storage schema or every connected system would be expensive, risky, or operationally impractical.

Legacy databases: Protect fixed-width fields without expanding the column.
Data pipelines: Keep values compatible with schemas and parsers that expect a particular character set.
Testing and analytics: Replace cleartext identifiers with reversible protected values where authorized recovery is still required.
Incremental modernization: Add protection to a constrained workflow while a broader architecture migration proceeds.

Current NIST guidance matters

NIST SP 800-38G originally specified FF1 and FF3 for format-preserving encryption. Research later identified weaknesses for small domains and in the FF3 family. NIST’s 2025 second public draft of SP 800-38G Revision 1 specifies FF1, removes FF3, raises the minimum FF1 domain size, disallows use of the inverse AES cipher function, and prohibits floating-point arithmetic in FF1 implementations.

This is an important operational lesson: do not choose an FPE algorithm by name alone. Confirm the exact standard revision, domain requirements, tweak handling, key length, library version, validation status, and migration plan. Teams using older FF3 or FF3-1 implementations should review their exposure against current NIST guidance.

FPE limitations and tradeoffs

FPE solves a compatibility problem, but it does not remove the need for careful security design.

Small domains reduce security. A field with few possible values gives an attacker a smaller space to analyze.
Patterns can remain meaningful. Deterministic use can reveal when two protected values are equal.
Format is not validity. Preserving length and characters does not automatically preserve checksums or business rules.
Key and tweak management still matter. Poor lifecycle controls can compromise a sound algorithm.
Authentication is a separate question. FPE does not automatically provide the same authenticated-encryption properties as AES-GCM.

FPE is not a replacement for tokenization or masking

FPE, tokenization, masking, and conventional encryption solve different problems. FPE is appropriate when reversible protection and format compatibility are both required. Tokenization can reduce the spread of original values and may be preferable when a token can be mapped or resolved through the chosen architecture. Masking is useful when a user or workflow needs only a limited representation rather than the original value.

The protection method should follow the workload, threat model, reversibility requirement, operational architecture, and identity’s authorized outcome. It should not be selected from a blanket hierarchy in which one method is always superior.

FPE implementation checklist

Inventory the exact field formats, lengths, character sets, and downstream validators.
Confirm the domain satisfies the current standard and implementation requirements.
Use a maintained implementation aligned with current NIST guidance.
Generate, store, rotate, and revoke keys through a documented lifecycle.
Define tweak construction and uniqueness rules explicitly.
Test collision, checksum, sorting, indexing, and integration behavior.
Record the algorithm and key version needed for later migration.
Apply authorization independently so only approved identities receive cleartext.

The bottom line

FPE can protect sensitive fields without forcing immediate database or application restructuring. Its compatibility benefits are strongest in constrained and legacy environments, but secure use depends on current algorithm guidance, adequate domain size, disciplined key management, and a clear understanding of what format preservation does not provide.

Learn how Ubiq applies FPE as one method within Format-Preserving Encryption and broader Runtime Data Protection.