A new Go API for JSON
- ID
- 43272
- Status
- summarized
- Published
- 05 Nov 2026, 1:52 AM
- Fetched
- 05 Nov 2026, 4:44 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://go.dev/blog/jsonv2
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.5
- Created
- 05 Nov 2026, 4:45 PM
- Tags
- Audience
- developersvibe_coders
What happened
The Go team published a post describing encoding/json/v2 and encoding/json/jsontext, now stable and generally available in Go 1.27 after last year's experimental release. The new API changes default behaviors that encoding/json got wrong: it rejects invalid UTF-8 rather than silently corrupting data (RFC 8259 requires valid UTF-8), rejects objects with duplicate member names instead of picking an arbitrary value, and addresses nil slices/maps marshaling to JSON null, which breaks consumers that disallow null where an array or object is expected. The post cites CVE-2017-12635 as a case where duplicate-name ambiguity was exploited.
Why it matters
If you decode untrusted JSON with encoding/json today, duplicate keys are resolved arbitrarily and invalid UTF-8 passes through silently — v2 flips both to errors, so any pipeline that currently tolerates sloppy payloads may start failing at the decode step after you adopt it. Also check cross-language boundaries: Go marshaling a nil slice or map as null already trips strict consumers, and that is one of the things the new packages address. Since v2 lives at a new import path, you can migrate package by package rather than all at once.
Discussion angle
Which of your services would break if JSON decoding started rejecting duplicate keys and invalid UTF-8 tomorrow — and is that breakage a bug you want surfaced or a compatibility risk you'd rather defer?