Go JSON Libraries: encoding/json vs jsoniter vs easyjson vs gojay vs Sonic

JSON serialization is a critical path in virtually every Go web service. The standard library’s encoding/json is correct and well-maintained but prioritizes simplicity over raw performance. For latency-sensitive APIs, data pipelines, and high-throughput services, specialized JSON libraries can deliver 2-10x speedups. This article compares five Go JSON libraries — encoding/json, jsoniter, easyjson, gojay, and Sonic — across performance, API compatibility, and tradeoffs.

Why Go JSON Performance Matters

Go services routinely handle millions of JSON payloads per second. At that scale, the difference between 500 ns and 50 ns per serialization is the difference between 1 CPU core and 10. JSON deserialization is particularly expensive because it requires runtime reflection in encoding/json to map arbitrary JSON structures to Go structs. Specialized libraries use code generation, SIMD instructions, and streaming parsers to eliminate this overhead.

Comparison Table

encoding/json: The Standard Baseline

Go’s encoding/json is universally available, thoroughly tested, and requires zero setup. It uses reflection to inspect struct tags at runtime, which is flexible but introduces overhead:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

package main

import (
    "encoding/json"
    "fmt"
)

type User struct {
    ID        int    `json:"id"`
    Name      string `json:"name"`
    Email     string `json:"email"`
    CreatedAt string `json:"created_at,omitempty"`
}

func main() {
    // Marshal: Go struct → JSON bytes
    user := User{ID: 1, Name: "Alice", Email: "alice@example.com"}
    data, err := json.Marshal(user)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(data))
    // Output: {"id":1,"name":"Alice","email":"alice@example.com"}

    // Unmarshal: JSON bytes → Go struct
    var decoded User
    err = json.Unmarshal(data, &decoded)
    if err != nil {
        panic(err)
    }
    fmt.Printf("%+v
", decoded)
}

For most applications, encoding/json is sufficient. Its streaming json.Encoder and json.Decoder handle large payloads efficiently by processing tokens one at a time. The primary limitation is that every Marshal/Unmarshal call traverses struct fields via reflection, which cannot be inlined or optimized by the Go compiler.

jsoniter: Drop-In Performance Boost

jsoniter (13,893 stars), or “json-iterator”, is designed as a 100% API-compatible replacement for encoding/json. You can switch from encoding/json to jsoniter by changing a single import alias:

1
2
3
4
5
6
7

import jsoniter "github.com/json-iterator/go"

// Use exactly the same API as encoding/json
var json = jsoniter.ConfigCompatibleWithStandardLibrary

data, _ := json.Marshal(user)
json.Unmarshal(data, &decoded)

jsoniter achieves its 2-3x speed improvement through optimized reflection — it caches type information and avoids repeated lookups. It supports all encoding/json features including custom marshalers (MarshalJSON/UnmarshalJSON), json.RawMessage, and omitempty. The drop-in compatibility makes jsoniter the lowest-risk performance upgrade: your existing tests pass, your existing structs work, and you get a significant speedup for free.

For even better performance, jsoniter offers a “fastest” configuration that sacrifices some rare features:

1
2
3
4

var json = jsoniter.ConfigFastest

// ~30% faster than CompatibleWithStandardLibrary
// Does NOT support: TextMarshaler, RawMessage, Number

easyjson: Compile-Time Code Generation

easyjson (4,903 stars) takes a fundamentally different approach — instead of reflection, it generates optimized marshal/unmarshal functions at build time. You annotate structs with //easyjson:json comments, run easyjson -all path/to/file.go, and it produces *_easyjson.go files:

1
2
3
4
5
6
7

// user.go — before code generation
//easyjson:json
type User struct {
    ID        int    `json:"id"`
    Name      string `json:"name"`
    Email     string `json:"email"`
}

After running easyjson -all user.go, a generated file provides type-specific functions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// user_easyjson.go — generated code
func (v User) MarshalEasyJSON(w *jwriter.Writer) {
    w.RawByte('{')
    w.RawString(""id":")
    w.Int(v.ID)
    w.RawString(","name":")
    w.String(v.Name)
    // ...
    w.RawByte('}')
}

// Usage (different API from encoding/json)
data, _ := v.MarshalJSON()
easyjson.Unmarshal(data, &decoded)

easyjson delivers 3-5x speedup over the standard library because the generated code has zero reflection overhead — it writes JSON bytes directly. The tradeoff is the extra build step (go generate or a Makefile target) and the slightly different API (you call .MarshalJSON() on the value rather than json.Marshal(value)). easyjson is ideal for data pipeline services where you process millions of identical structs and can accept the generated-code workflow.

gojay: Streaming-First High Performance

gojay (2,135 stars) is built around a streaming API that encodes/decodes JSON without building intermediate representations. It avoids allocating a fully parsed struct for decoding — instead, you provide callbacks that process fields as they’re encountered:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import "github.com/francoispqt/gojay"

type User struct {
    ID    int
    Name  string
    Email string
}

// Implement gojay.UnmarshalerJSONObject
func (u *User) UnmarshalJSONObject(dec *gojay.Decoder, key string) error {
    switch key {
    case "id":
        return dec.Int(&u.ID)
    case "name":
        return dec.String(&u.Name)
    case "email":
        return dec.String(&u.Email)
    }
    return nil
}

func (u *User) NKeys() int { return 3; }

// Marshal
func (u *User) MarshalJSONObject(enc *gojay.Encoder) {
    enc.IntKey("id", u.ID)
    enc.StringKey("name", u.Name)
    enc.StringKey("email", u.Email)
}

func (u *User) IsNil() bool { return u == nil; }

gojay achieves 5-10x speedups for two reasons: it never uses reflection, and its streaming decoder can skip unknown fields without allocating memory for them. This is ideal for ETL pipelines, log processing, and API gateways where you need to extract a few fields from massive JSON payloads. The main downside is the verbose interface implementation — each struct needs MarshalJSONObject/UnmarshalJSONObject methods, which is more boilerplate than struct tags.

Sonic: ByteDance’s SIMD Speed Demon

Sonic (9,523 stars), developed by ByteDance (the company behind TikTok and Douyin), uses Just-In-Time compilation and SIMD (Single Instruction Multiple Data) instructions to achieve 4-8x speedups. It’s API-compatible with encoding/json:

1
2
3
4
5

import "github.com/bytedance/sonic"

// Direct drop-in replacement
data, _ := sonic.Marshal(&user)
sonic.Unmarshal(data, &decoded)

Sonic’s secret is its JIT compiler that generates optimized assembly at runtime using the same techniques as modern JavaScript engines. It uses AVX2 SIMD instructions on AMD64 processors to parse JSON in parallel — processing 32 bytes at a time (AVX-512 on newer CPUs). However, Sonic only works on AMD64 Linux/macOS — it falls back gracefully on ARM (Apple Silicon) but doesn’t achieve its full performance on those architectures.

The JIT approach means the first few calls are slower (JIT compilation overhead) but subsequent calls are extremely fast. Sonic automatically detects CPU features at runtime and selects the optimal code path:

1
2
3
4
5
6
7
8

import (
    "github.com/bytedance/sonic"
    "github.com/bytedance/sonic/ast"
)

// Sonic also provides a DOM-style API for partial parsing
node, _ := sonic.Get(data, "users", 0, "name")
fmt.Println(node.String()) // Extract nested field without full deserialization

Performance Benchmarks

While specific numbers depend on payload size and structure complexity, general benchmarks across small (<1 KB), medium (10 KB), and large (100 KB) JSON payloads show:

Sonic particularly excels at decoding — the SIMD parser handles common JSON patterns (strings, numbers) in parallel, while gojay’s streaming decoder avoids memory allocation overhead for unknown fields.

Why Self-Host Your Go JSON Performance Knowledge?

Understanding JSON serialization performance is critical for Go services that handle API requests, process event streams, or transform data between formats. The right library choice can reduce your service’s CPU footprint by 50-80%. For related Go developer tooling, see our Go serialization libraries comparison covering binary formats beyond JSON. Our Go task queue guide covers patterns for processing JSON payloads in background workers. For email integration in Go services, check our Go email libraries comparison.

FAQ

Can I just use encoding/json for production services?

Yes, for the vast majority of Go services, encoding/json is perfectly adequate. Only optimize when profiling shows JSON serialization consuming >10% of CPU time. The standard library’s correctness, security track record, and zero-dependency guarantee make it the safest default choice.

Is Sonic production-ready outside of ByteDance?

Yes. Sonic has been adopted by many organizations beyond ByteDance and has a stable v1 API. However, the AMD64-only constraint means you need separate build configurations for ARM deployments (e.g., AWS Graviton). For cross-platform services, use Sonic as an AMD64 optimization with encoding/json as the ARM fallback via a build-tag pattern.

How does jsoniter compare to easyjson for a new project?

Choose jsoniter if you want minimal code changes (import swap) and don’t want a code generation step in your build pipeline. Choose easyjson if you’re willing to run easyjson -all as part of go generate and want the absolute best performance without runtime JIT overhead or platform constraints. easyjson’s generated code is also more reviewable — you can inspect exactly what the marshal/unmarshal functions do.

Does gojay work with existing encoding/json struct tags?

No. gojay requires explicit MarshalJSONObject/UnmarshalJSONObject method implementations — it doesn’t read struct tags. This makes it less ergonomic for large codebases with many struct types. Use gojay when you have a small number of high-volume structs (e.g., a message queue protocol) where the manual implementation effort is justified by the performance gains.

What about goccy/go-json or segmentio/encoding?

goccy/go-json (another high-performance alternative) uses code generation similar to easyjson but with an encoding/json-compatible API. segmentio/encoding (1,052 stars) focuses on correctness with moderate performance gains. Both are viable alternatives — the choice between Sonic, easyjson, and jsoniter depends on your deployment architecture (AMD64 vs ARM) and whether you can accept a code generation step.

Is JSON still the right choice for internal service communication?

For internal service-to-service communication, consider Protocol Buffers (protobuf) with gRPC instead of JSON. Protobuf eliminates parsing overhead entirely through efficient binary encoding. See our Go serialization guide for protobuf setup in Go. JSON remains ideal for public APIs, browser-facing endpoints, and debugging (human-readable).

💰 想测试你的市场判断力？我用 Polymarket 做预测市场交易——这是全球最大的预测市场平台，从大选结果到技术监管时间线，什么都可以押注。和赌博不同，这是真正的信息市场：你懂的信息越多，胜率越高。我靠预测技术相关事件的走向已经赚了不少。用我的邀请链接注册：Polymarket.com