Validation modes: before, after, strict, lax

Two independent axes, routinely confused. Before/after is when your validator runs relative to Pydantic’s own parsing. Strict/lax is whether Pydantic coerces at all.

Before and after

raw input ──▶ [before] ──▶ Pydantic coercion ──▶ [after] ──▶ field

after is the default. Your validator receives the value already coerced to the field’s type, which is what you want most of the time — you are checking a business rule, not parsing.

class Product(BaseModel):
    price: Decimal

    @field_validator("price")          # mode="after"
    @classmethod
    def positive(cls, v: Decimal) -> Decimal:
        if v <= 0:
            raise ValueError("must be positive")
        # v is a Decimal here
        return v

mode="before" receives the raw input, whatever it is, and runs instead of letting Pydantic see it first. Reach for it only when the input needs normalising into something the parser can handle:

class Product(BaseModel):
    price: Decimal

    @field_validator("price", mode="before")
    @classmethod
    def strip_currency(cls, v):
        if isinstance(v, str):
            return v.replace("£", "").replace(",", "")
        # v may be anything
        return v

Note the isinstance check. A before validator has no type guarantee at all, so it must handle whatever arrives — that is the cost of running first.

Getting this backwards is a real bug: a business rule in before compares against a string it assumed was an int, and a normaliser in after never runs because parsing already rejected the input.

Model validators take the same modes

@model_validator(mode="before")
@classmethod
def unwrap_envelope(cls, data):
    # a dict, pre-parse
    return data.get("payload", data)

@model_validator(mode="after")
def dates_ordered(self):
    if self.end <= self.start:          # a real model
        raise ValueError("end must be after start")
    return self

before gets the raw dict, which is how you reshape a payload — unwrapping an envelope, renaming a legacy key. after gets the constructed model with every field typed, which is where cross-field rules belong.

Strict and lax

Lax is the default: Pydantic coerces where it safely can. Strict rejects anything that is not already the right type.

class Lax(BaseModel):
    n: int

class Strict(BaseModel):
    n: int
    model_config = ConfigDict(strict=True)

Lax(n="42").n        # 42
Strict(n="42")       # ValidationError

strict is available per field, per model and per call (model_validate(data, strict=True)), so you can be strict about an amount and lax about everything else.

Gotcha: JSON has no integers-versus-floats distinction the way Python does, and no dates at all. A strict model fed a JSON body rejects "2026-01-01" for a date field, because in strict mode a string is not a date. Strict belongs behind the boundary, not on it.

Related

• Pydantic in practice — where models sit in an app
• FastAPI and the event loop — the boundary they validate