httpx Form-encoded data with `None` as the value gets

The Fix

Upgrade to version 0.18.0 or later.

Based on closed encode/httpx issue #1500 · PR/commit linked

Jump to Verify Open PR/Commit

@@ -21,6 +21,7 @@
     ResponseContent,
 )
+from ._utils import primitive_value_to_str

repro.py

import requests
import httpx

url = 'https://httpbin.org/post'
data = dict(foo=None)

resp_requests = requests.post(url, data=data)
pprint(resp_requests.json())
# In the response:  'form': {},

resp_httpx = httpx.post(url, data=data)
pprint(resp_httpx.json())
# In the response:  'form': {'foo': 'None'},

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

fix.md

Option A — Upgrade to fixed release\nUpgrade to version 0.18.0 or later.\nWhen NOT to use: This fix is not suitable if the application relies on 'None' being passed as a string.\n\nOption C — Workaround\nfor me. However, for compatibility with requests, converting `None` to empty string will not yield identical results, since then the empty string is in fact passed with the `POST` request.\nWhen NOT to use: This fix is not suitable if the application relies on 'None' being passed as a string.\n\n

Why This Fix Works in Production

Trigger: In other words, remove anything that doesn't make the bug go away.
Mechanism: The library converts None values to the string 'None' when encoding form data
Why the fix works: Addresses the issue of `None` values being passed as the string 'None' in form-encoded data. (first fixed release: 0.18.0).

Production impact:

If left unfixed, this can cause silent data inconsistencies that propagate (bad cache entries, incorrect downstream decisions).

Why This Breaks in Prod

The library converts None values to the string 'None' when encoding form data
Production symptom (often without a traceback): In other words, remove anything that doesn't make the bug go away.

Proof / Evidence

GitHub issue: #1500
Fix PR: https://github.com/encode/httpx/pull/1539
First fixed release: 0.18.0
Reproduced locally: No (not executed)
Last verified: 2026-02-09
Confidence: 0.85
Did this fix it?: Yes (upstream fix exists)
Own content ratio: 0.77

Discussion

High-signal excerpts from the issue thread (symptoms, repros, edge-cases).

Jump to Sources Open on GitHub

“Other relevant threads: * https://github.com/psf/requests/issues/378 - Resolved by https://github.com/psf/requests/pull/805 (exclude None value, ie the current behavior of Requests) * #154 (for query string, rather than…”

@florimondmanca · 2021-03-08 · confirmation · source

“Personally I think requests' behaviour here is unintuitive”

@lovelydinosaur · 2021-03-09 · source

“Do you consider this a bug, or just "behaves differently"?”

@pletnes · 2021-03-08 · source

“Hi :) For some reason this rings a bell”

@florimondmanca · 2021-03-08 · source

Failure Signature (Search String)

In other words, remove anything that doesn't make the bug go away.
Or raising a loud error as "this is ambiguous"?

Copy-friendly signature

signature.txt

Failure Signature
-----------------
In other words, remove anything that doesn't make the bug go away.
Or raising a loud error as "this is ambiguous"?

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
In other words, remove anything that doesn't make the bug go away.
Or raising a loud error as "this is ambiguous"?

Minimal Reproduction

repro.py

import requests
import httpx

url = 'https://httpbin.org/post'
data = dict(foo=None)

resp_requests = requests.post(url, data=data)
pprint(resp_requests.json())
# In the response:  'form': {},

resp_httpx = httpx.post(url, data=data)
pprint(resp_httpx.json())
# In the response:  'form': {'foo': 'None'},

What Broke

Form data sent to the server contains unexpected string 'None', causing potential data handling issues.

Why It Broke

The library converts None values to the string 'None' when encoding form data

Fix Options (Details)

Option A — Upgrade to fixed release Safe default (recommended)

Upgrade to version 0.18.0 or later.

When NOT to use: This fix is not suitable if the application relies on 'None' being passed as a string.

Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.

Option C — Workaround Temporary workaround

for me. However, for compatibility with requests, converting `None` to empty string will not yield identical results, since then the empty string is in fact passed with the `POST` request.

When NOT to use: This fix is not suitable if the application relies on 'None' being passed as a string.

Use only if you cannot change versions today. Treat this as a stopgap and remove once upgraded.

Fix reference: https://github.com/encode/httpx/pull/1539

First fixed release: 0.18.0

Last verified: 2026-02-09. Validate in your environment.

When NOT to Use This Fix

This fix is not suitable if the application relies on 'None' being passed as a string.

Verify Fix

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

Did This Fix Work in Your Case?

Quick signal helps us prioritize which fixes to verify and improve.

Prevention

Add a CI check that diffs key outputs after upgrades (OpenAPI schema snapshots, JSON payload shapes, CLI output).
Upgrade behind a canary and run integration tests against the canary before 100% rollout.
Add a TLS smoke test that performs a real handshake in CI (include CA bundle validation and hostname checks).
Alert on handshake failures by error string and endpoint to catch cert/CA changes quickly.

Version Compatibility Table

Version	Status
0.18.0	Fixed

Related Issues

No related fixes found.

Cluster: httpx:data-consistency All hubs All clusters

Related clusters: Configuration error Other Timeout

Sources

We don’t republish the full GitHub discussion text. Use the links above for context.

httpx Form-encoded data with `None` as the value gets passed as string "None" (Fix)