Go's new JSON package: the rewrite stdlib developers have waited 15 years for

What happened

The Go team published an official blog post introducing `encoding/json/v2`, a ground-up rewrite of the package that virtually every production Go service depends on. This is not a patch release. It's a parallel package that reimagines JSON handling in Go after 15 years of accumulated workarounds, performance complaints, and API regrets. The package was proposed in discussion #71497, developed in a public experimental repo, and is now landing in the standard library behind the `GOEXPERIMENT=jsonv2` flag with a target of stable availability in an upcoming Go release.

The headline numbers, drawn from the proposal's benchmarks: marshaling is roughly 2-3x faster than v1 for typical payloads, and unmarshaling is 2-9x faster depending on structure depth and type complexity. The gains come from a redesigned tokenizer that operates on byte slices without intermediate allocations, a cleaner separation between syntactic and semantic processing, and the removal of reflection from the hot path for common types.

The v1 package isn't going away. Instead, `encoding/json` v1 is being re-implemented as a thin shim that delegates to v2 under a compatibility mode. Existing code continues to compile and behave identically. New code that imports `encoding/json/v2` opts into the new semantics and the new API surface.

Why it matters

The `encoding/json` package has been one of Go's most-complained-about standard library components for over a decade. The complaints aren't academic — they're the kind of thing that costs engineering teams real time. You cannot turn off HTML escaping without wrapping an `Encoder`. You cannot reject unknown fields without a separate method call that only works on the decoder, not on `Unmarshal`. You cannot customize time formatting without implementing `MarshalJSON` on every type that embeds a `time.Time`. Duplicate object keys are silently accepted, which has been the root cause of multiple security advisories across the Go ecosystem.

v2 addresses each of these with an `Options` pattern — functional options passed to `Marshal` and `Unmarshal` that compose cleanly. Want to reject unknown fields? `json.RejectUnknownMembers(true)`. Want to marshal with indentation? `jsontext.WithIndent(" ")`. Want a specific time format? `json.FormatTimeWithLegacySemantics(false)` plus a time-specific option. The old pattern of wrapping encoders/decoders in builder chains, or worse, defining custom types just to get one knob, is gone.

The performance story deserves a closer look. The v2 proposal cites benchmarks against `encoding/json` v1, `jsoniter`, `goccy/go-json`, and `segmentio/encoding`. v2 beats v1 across the board, and for marshaling it approaches `goccy/go-json` — the fastest third-party library most Go teams reach for. For unmarshaling deeply nested structures, v2 is often faster than all of them because it avoids the reflection-heavy decode paths the others still rely on for edge cases. If you've been running `jsoniter` or `goccy/go-json` in production purely for the speedup, v2 removes the main reason to carry a non-stdlib dependency for JSON.

The semantic changes are the part that will trip teams up on migration. `time.Time` now serializes to RFC 3339 with nanoseconds by default, where v1 used the `MarshalJSON` method's RFC 3339 variant without sub-second precision in some paths. `nil` slices marshal to `null` instead of `[]` by default — a change that reverses one of the most-asked-about v1 behaviors, but one that will break clients expecting empty arrays. Duplicate object keys in incoming JSON cause an error by default, which is the correct behavior per RFC 8259 but will reject inputs from sloppy upstream systems. Each of these has an option to restore v1 semantics, but the defaults are different.

Community reaction on the Hacker News thread has been uncharacteristically positive for a Go announcement. The top comments focus on how long this has taken — Daniel Martí, Russ Cox, and Joe Tsai have been iterating on this for years in public — and on relief that the Go team is willing to break from the original API's defaults when the original defaults were wrong. The subtext is that Go, famously allergic to breaking changes, has found a path to meaningful improvement via parallel packages rather than version bumps. That pattern, if it holds, matters as much as the JSON changes themselves.

What this means for your stack

If you maintain a Go service, the migration calculus is simple for now: do nothing. v1 continues to work, backed by v2's implementation, which means you get some of the performance improvements for free when you upgrade Go. Benchmark your hot paths after the Go version bump — some workloads will see 20-40% throughput improvements on JSON-heavy endpoints with zero code changes.

When you're ready to opt in, pick one service with a well-defined JSON surface and migrate it. The import path changes from `encoding/json` to `encoding/json/v2`, and you'll want to audit three things: time serialization (are clients parsing RFC 3339 with nanoseconds?), empty slice handling (does any downstream consumer rely on `[]` instead of `null`?), and duplicate key tolerance (does your API accept merged payloads from legacy clients?). The `FormatNilSliceAsNull(false)` and `AllowDuplicateNames(true)` options restore v1 behavior if you need a staged rollout.

For library authors, v2 is where you want to be. The `MarshalerV2` and `UnmarshalerV2` interfaces give you access to the tokenizer directly, which means you can write custom marshalers that don't allocate an intermediate `[]byte`. If you ship a JSON-adjacent library (query builders, schema validators, config parsers) and you currently take a `json.RawMessage` or `[]byte`, consider adding a v2-aware path. The performance delta is large enough that users will notice.

Looking ahead

The deeper story here is about stdlib governance. Go's team has historically defended the standard library's stability to a fault, which meant that known-bad APIs calcified for a decade. v2 proves there's a middle path: keep the old package working as a compatibility layer, put the new design behind a new import path, and let the ecosystem migrate on its own schedule. If `encoding/json/v2` lands cleanly, expect the same pattern applied to `net/http` (the `http.Handler` shape has its own list of regrets) and `database/sql` (which has been begging for a v2 since context support landed). The JSON rewrite isn't just a faster parser — it's a template for how Go evolves its most entrenched APIs without breaking the production code that depends on them.