Address Format in France: Complete Guide 2026

France uses a 5-digit postal code written immediately before the locality name, with no letters, spaces, or hyphens in the code itself. For domestic mail, the standard structure is capped at six lines, typically arranged like this:

RECIPIENT
BUILDING / APT / STAIRCASE / ENTRANCE
HOUSE NUMBER + STREET NAME
DELIVERY SERVICE INFO OR LIEU-DIT
POSTAL CODE LOCALITY
FRANCE only if the mail is international

If you're debugging failed deliveries, broken geocodes, or messy CRM imports, the problem usually isn't “France is hard.” It's that French addresses are more structured than many generic address schemas expect. The format looks simple until you hit apartment blocks, lieu-dit records, CEDEX routing, or a pipeline that flattens everything into one street line.

A workable mental model is this:

• Postal code is strict: exactly 5 digits
• Ordering matters: recipient first, locality line near the end
• Secondary unit details matter: apartment, floor, staircase, entrance often carry delivery-critical information
• Business routing is different: CEDEX changes how the locality line works
• Data models can lose information: especially when mapping French address records into broader international schemas

That's where most parsers fail. The rest of this guide focuses on what works when you need to validate, normalize, and enrich French addresses programmatically.

Why Getting the French Address Format Right Matters

A bad French address usually fails in quiet ways. The package might still arrive late. The lead record might still save. The validation API might still return “valid” while dropping the apartment or building field that the carrier needs.

In France, address formatting isn't loose human convention. It's a structured postal record. The Universal Postal Union guidance and commercial formatting references align on a rigid pattern: recipient, optional delivery details, street line, then a final locality line built around the postal code and city name. That rigidity is exactly why French address data is workable at scale if you model it correctly, and painful if you don't.

If you're handling shipments into France, a forwarding workflow like AUSFF services for France is useful context because it exposes the practical side of these formatting rules. Once mail crosses systems, formatting mistakes stop being cosmetic and start affecting routing, matching, and exception handling.

What breaks in real systems

Three failure patterns show up repeatedly:

• Secondary details get buried: Developers often append apartment, floor, or staircase details to the end of the street line. That looks harmless, but it conflicts with French line ordering and makes parsing harder downstream.
• The locality line gets split incorrectly: In France, the postal code and locality belong together. Treating them as free-text fragments creates avoidable validation ambiguity.
• Generic validators overfit Anglo formats: If your stack assumes “street line 1, street line 2, city, state, ZIP,” you'll end up forcing French records into the wrong shape.

Practical rule: Treat a French address as a sequence of typed components, not as a mailing label string.

For developers building ingestion or matching pipelines, this is the same broader problem covered in this guide to address verification. Validation isn't just “does this exist.” It's “did we preserve the routing-relevant parts in the correct order.”

What good handling looks like

A solid implementation does three things well:

1. Separates component parsing from label rendering
2. Preserves all delivery-point details even when upstream systems don't
3. Applies French-specific ordering only at output or canonicalization time

That approach gives you one canonical record for matching, and multiple renderings for domestic mail, international mail, or API export.

How Is a Standard French Address Structured

A standard French address is highly ordered. The recipient comes first, optional delivery details come next, the street line follows, and the final locality line combines the postal code with the locality name. For international mail, the destination country is added on the last line, and common guidance notes six lines domestically and seven for international mail in GeoPostcodes' France address format reference.

Copy-paste template

Use this as your base template for domestic records:

RECIPIENT
ATTENTION OR SERVICE
APARTMENT / FLOOR / STAIRCASE / ENTRANCE
HOUSE NUMBER + STREET NAME
LIEU-DIT OR PO BOX IF APPLICABLE
POSTAL CODE LOCALITY

For international output, add the country as the final line.

French address line structure

The ordering logic

French formatting follows a most specific to most general progression. That matters because each line narrows the delivery target before the final locality line confirms the routing area.

What doesn't work well is freeform concatenation. If you dump everything into one address field, you can still print a label, but you lose predictable parsing. Once that happens, deduping, geocoding, and validation all get harder.

Keep your storage model richer than your print model. A label is an output format, not the source of truth.

The engineering takeaway

Don't build your parser around visual line count alone. Build it around component classes:

• Recipient
• Organizational routing
• Delivery-point detail
• Street access line
• Special routing or locality supplement
• Postal code plus locality
• Country for international output

That distinction is what lets you format correctly even when the input arrives as a single messy string.

What Are the Core Components of a French Address

The core components are straightforward until you hit dense urban housing. Then the distinction between delivery-point info, building info, and street info stops being semantic and starts determining whether the item reaches the right door.

The most useful rule comes from the UPU guidance for France: addressee, then delivery-point info such as apartment, floor, hallway, or staircase, then geographical info such as entrance or building, then the house number and street. It also specifies a cap of 38 characters or spaces per line in the official UPU France addressing guide.

Delivery-point details are not decoration

In many countries, unit details are often optional for machine validation and only matter for final-mile delivery. In French urban addresses, they often carry the actual access path.

Useful examples of delivery-point detail categories include:

• Apartment info: apartment or flat identifier
• Vertical location: floor
• Internal pathing: hallway or staircase
• Access segmentation: entrance or building reference

If your parser collapses all of these into “address line 2,” that's acceptable for storage only if you also preserve their original order.

Street line rules

The street line should place the house number before the street name, as naive parsers trained on mixed-country data often tolerate both orders and then normalize inconsistently.

A practical parser should:

• detect a leading building number when present
• preserve the full street type and street name as one unit
• avoid moving apartment or building markers onto the street line unless the source was already unrecoverably flattened

Why simple templates fail

A lot of product teams use a minimal template:

• name
• street
• postal code
• city

That works for low-density residential exports. It fails for multi-unit buildings, mixed-use buildings, and institutional addresses. The failure mode is subtle. The address can still look complete while missing the exact descriptor the local carrier or internal routing point needs.

If you only store what a checkout form asks for, you'll throw away the data the carrier actually uses.

Line discipline matters

Because French address lines are constrained, line wrapping can't be arbitrary. If your rendering logic inserts breaks based only on character count, you can split related delivery details into unusable fragments.

The safer pattern is:

1. parse into typed fields
2. rank components by postal priority
3. render into lines with controlled overflow rules
4. only then apply line-length constraints

That gives you a label that's both human-readable and closer to the postal model.

How Do French Postal Codes Work

French postal codes are a strictly numeric 5-digit field. The first two digits identify the département, and the remaining three specify the delivery zone or locality. The code is written immediately before the locality name on the same line, with no letters, spaces, or hyphens inside the code itself, as described in Melissa's France address formatting reference.

What the digits tell you

The useful part for validation is that French postal codes carry geography.

Paris is the standard example because its codes begin with 75. Overseas territories commonly use codes beginning with 97.

What to validate programmatically

The easiest low-level check is syntax:

• Regex: ^[0-9]{5}$

That only validates shape, not correctness. A string can be five digits and still point to the wrong locality. Your application should therefore separate:

• format validation
• postal code to locality validation
• business-rule validation such as whether a CEDEX recipient should use a CEDEX locality line

Common implementation mistakes

A few mistakes show up constantly:

• Accepting spaces or hyphens inside the code
• Storing the postal code as an integer, which can create downstream formatting issues in some systems
• Splitting the postal code and locality into unrelated fields without preserving the display relationship

The cleanest design is to store the postal code as a string and render the postal code plus locality as a single output line.

How to Handle Special French Address Formats

Special French address formats are where generic address tooling usually breaks. The important cases are CEDEX, Boîte Postale or BP, and lieu-dit. Each changes the routing logic enough that you shouldn't treat it as just another optional text fragment.

CEDEX

CEDEX is a dedicated routing designation for organizations receiving high volumes of mail. The town name may be followed by CEDEX and sometimes a 1- or 2-digit number, which signals a distinct business-routing system in the address format reference covering CEDEX.

This changes two implementation assumptions:

• the locality line may not be a plain postal-code-plus-city record
• your validator can't “correct” CEDEX away just because it doesn't match a residential pattern

A practical CEDEX locality line might include:

• postal code
• locality name
• CEDEX
• optional CEDEX number

If you're building canonical schemas, store CEDEX as its own flag or subtype rather than burying it inside locality text only.

BP and postal routing lines

BP indicates a post office box style routing line. It isn't interchangeable with a street address, and it shouldn't be merged into the street field.

A workable storage approach is:

Lieu-dit

A lieu-dit is a named place, often used in rural areas where the address doesn't behave like a standard urban street address. This is exactly the kind of component that simplistic parsers either drop or misclassify as a street name.

What works:

• preserve lieu-dit as a distinct component
• allow it to appear before the postal code line
• don't force a fake street number if the source address doesn't contain one

What doesn't work:

• mapping lieu-dit into “address line 2” without semantic tagging
• overwriting it when geocoding returns a more generic road segment
• assuming every deliverable French address must include a conventional street line

Decision rule for edge cases

When an address contains one of these special formats, classify it first:

1. Street-delivery address
2. Post-box style address
3. High-volume business routing address
4. Named-place rural address

Once you've classified it, line rendering becomes predictable. Most validation failures happen because teams try to normalize first and classify later.

How to Format Addresses for International Mail to France

For international mail to France, keep the French domestic structure intact and add FRANCE as the last line. The French address standard remains the same, with international formatting adding the destination country on the final line.

That means you shouldn't translate the internal address components into English. Keep Rue, Boulevard, locality names, and other French elements as they are in the destination address. Translation makes the address friendlier to the sender, not to the receiving postal system.

Safe international template

Use this rendering:

RECIPIENT
BUILDING / APARTMENT / DELIVERY DETAILS
HOUSE NUMBER + STREET NAME
DELIVERY SERVICE INFO OR LIEU-DIT
POSTAL CODE LOCALITY
FRANCE

Practical validation advice

If you're validating outbound international records, focus on two things:

• preserving the French internal ordering
• ensuring the country is the final line

If you need a broader framework for cross-border validation rules, this guide to validate international address records is a useful companion. The core point is simple. International shipping doesn't erase local postal rules. It adds one more routing layer on top of them.

How to Programmatically Normalize French Addresses

Manual formatting doesn't scale. It fails when records come from web forms, broker feeds, CRM exports, parcel APIs, and scanned documents that all disagree about line order. For French addresses, normalization only works if you preserve component meaning before you standardize appearance.

A normalization pipeline that actually works

Use a staged pipeline instead of a single regex-heavy cleanup pass.

1. Ingest raw input

   • single string or multi-line input
   • preserve original text for auditability

2. Parse into typed components

   • recipient
   • organization or service
   • delivery-point details
   • building or entrance info
   • street line
   • delivery service info
   • postal code
   • locality
   • country

3. Normalize representation

   • uppercase output lines if your downstream postal rendering requires it
   • standardize punctuation rules
   • keep accents and French characters intact unless a specific downstream system can't accept them

4. Validate structure

   • use ^[0-9]{5}$ for postal code shape
   • ensure locality is paired with the postal code line
   • detect CEDEX, BP, and lieu-dit before street normalization

5. Render for target schema

   • domestic label
   • international label
   • API payload
   • warehousing table

The ISO 20022 problem

One of the biggest integration traps is schema mismatch. The French standard NF Z 10-011 includes a name line that isn't represented in the ISO 20022 postal address structure. If you map directly without preserving that extra information separately, you lose data, as noted in Smarty's discussion of La Poste and French address structure.

This matters in enterprise systems because “name” often isn't just presentation. It can be the entity that distinguishes one valid recipient from another at the same destination.

Don't flatten French address records into an international schema without a sidecar field for unmapped components.

What to normalize and what to preserve

Some transformations are safe. Others are destructive.

The dangerous step is heuristic reordering. If a source line contains apartment, staircase, and building info in a valid local sequence, don't “clean it up” into an Anglo-style unit suffix.

For teams building data products, address standardization methods for real estate data is a useful reference because it frames the broader storage problem well. In tooling terms, BatchData also offers an address format standardization workflow, which fits naturally into pipelines that need canonical records before matching or enrichment.

Implementation notes for developers

A few practical choices reduce pain:

• Store postal code as text
• Keep a raw input field
• Version your normalization rules
• Tag special formats explicitly
• Separate canonical storage from printable output

If you do that, French addresses stop being “special cases” and become just another well-structured national format with a few routing-specific branches.

French Addressing Common Questions Answered

How should you handle a French military address

Use the same general discipline: preserve the address exactly as issued and don't force it into a civilian street schema if it uses a specialized routing designation. For military-style records, the safe approach is to classify first, then render according to the issuing format rather than trying to infer a street and locality pattern.

Is there an official master list of French street abbreviations

There are common abbreviations in practice, but your parser shouldn't depend on a hardcoded abbreviation list alone. Use abbreviation handling as a normalization aid, not as your primary parser. The moment you rely on abbreviation expansion to infer structure, you'll misread edge cases and legacy records.

What if an address has both lieu-dit and a street name

Preserve both if the source includes both. Treat lieu-dit as a geographic locality component and the street as the access line. Don't overwrite one with the other just because your UI only exposes a single extra-address field.

Should you reject an address that doesn't look like a standard urban template

No. Rejecting non-urban or special-routing formats creates false negatives. A better rule is to validate against known French address patterns, plural, instead of one rigid residential template.

The parser should recognize when an address is unusual. It shouldn't assume unusual means wrong.

If you're building products that ingest, clean, or match location data at scale, BatchData is worth evaluating for address normalization workflows alongside property and location-linked data pipelines. That's especially relevant when your system needs a canonical address record before validation, enrichment, or downstream real estate analysis.