- FastAPI 0.147.0, released October 19, 2026, reads omitted boolean form fields as False, including fields whose default is True or None. The maintainers label it a bug fix.
- The inferred False counts as explicitly set. JSON requests and direct Pydantic validation are unchanged, according to the release notes.
- Before upgrading, ask teams which form endpoints take yes/no fields, and whether any non-browser client posts to them.
A default is a promise about what happens when nobody speaks. FastAPI 0.147.0, released on October 19, 2026, rewrites that promise for one kind of input: a yes/no field missing from a web form. This is our analysis of what that change means.
What changed in 0.147.0
The maintainers list the change under a bug-fix label: "Treat omitted boolean form fields as False." Their stated aim is to match how unchecked HTML checkboxes behave.
The rule applies to bool and bool | None fields. It holds for single Form parameters and for form models. A field may be required, or may default to True or None. If the form leaves it out, the value is now False.
Two areas are untouched. JSON request bodies work as before. So does calling Pydantic directly. Pydantic is the library FastAPI uses to check incoming data.
Why checkboxes force the question
A browser sends a checked box along with the form. An unchecked box sends nothing at all. The form cannot say "no". It can only stay silent.
A framework must decide what that silence means. From 0.147.0, FastAPI reads it as the browser user intended: the box was unchecked, so the answer is False.
A before-and-after example
Here is an illustration, not a case from the release notes. Picture a form model with a field written as notify: bool = True. A client posts the form with a name but no notify value.
The notes do not describe the old behaviour. We infer that the declared default applied, so notify was stored as True. We also infer that a required field with no default would have been a missing-value error. Under 0.147.0, the same post gives notify as False.
For a person who unticked a box in a browser, the new result matches what they meant. That is the case the maintainers describe.
Why exclude_unset matters
Pydantic keeps track of which fields a client actually supplied and which it filled in from defaults. Calling model_dump(exclude_unset=True) returns only the supplied fields. Update code often uses it to write just what the user sent.
The notes say the inferred False counts as explicitly set. So notify now appears in that output. Our reading is that update code saving only supplied fields would now write False to storage. Before, we infer, an omitted field would have been left out and the stored value left alone. The maintainers do not discuss this case.
Where to look
The maintainers frame this as a fix that aligns FastAPI with browsers, and for browser forms it likely does. We have no sourced case of harm. The open question is non-browser clients, such as scripts and integrations that post form data. The notes do not address them. If one omits a field, it now gets False.
The notes also do not say how many applications are affected, and they give no migration path. A separate pull request by @YuriiMotov adds framework tests for defaults, nullable fields and browser-style form posts. Those tests cover FastAPI. They do not cover your own application.
Questions to put to your team
Which of our endpoints accept form data, and which of those have yes/no fields? Do any of those fields default to True or None?
Do clients other than browsers post to them? Does any such field drive a stored setting, such as notifications or sharing? Does any update code save only supplied fields?
Do our tests cover the case where the field is missing? Run that case against 0.147.0 before the upgrade reaches production.
When a framework changes what silence means, someone should check who was relying on the old promise.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub (fastapi/fastapi).
