Open Source Go JSON Serialization Libraries

Go module implementing various JWx (JWA/JWE/JWK/JWS/JWT, otherwise known as JOSE) technologies. If you are using this module in your product or your company, please add your product and/or company name in the Wiki! It really helps keeping up our motivation. Complete coverage of JWA/JWE/JWK/JWS/JWT, not just JWT+minimum tool set. Supports JWS messages with multiple signatures, both compact and JSON serialization. Supports JWS with detached payload. Supports JWS with unencoded payload (RFC7797). Supports JWE messages with multiple recipients, both compact and JSON serialization. Most operations work with either JWK or raw keys e.g. *rsa.PrivateKey, *ecdsa.PrivateKey, etc). Opinionated, but very uniform API. Everything is symmetric, and follows a standard convention. Arguments are organized as explicit required paramters and optional WithXXXX() style options.

Arbitrary-precision fixed-point decimal numbers in go. Note: Decimal library can "only" represent numbers with a maximum of 2^31 digits after the decimal point. The zero-value is 0, and is safe to use without initialization. Addition, subtraction, and multiplication with no loss of precision. Division with specified precision. Database/sql serialization/deserialization. JSON and XML serialization/deserialization. big.Int's API is built to reduce the number of memory allocations for maximal performance. This makes sense for its use-case, but the trade-off is that the API is awkward and easy to misuse. In contrast, it's difficult to make such mistakes with decimal. Decimals behave like other go numbers types: even though a = b will not deep copy b into a, it is impossible to modify a Decimal, since all Decimal methods return new Decimals and do not modify the originals. The downside is that this causes extra allocations, so Decimal is less performant.

Twirp is a simple RPC framework built on protobuf. You define a service in a .proto specification file, then Twirp will generate servers and clients for that service. It's your job to fill in the "business logic" that powers the server, and then generated clients can consume your service straight away. Twirp routing and serialization reduces the risk of introducing bugs. Both JSON and Protobuf are supported. The Protobuf protocol is designed to allow backwards compatible changes (unlike JSON, it is trivial to rename fields). Protobuf is super fast and the proto file definition also works well as documentation for your service. Twirp is similar to gRPC, but without the custom HTTP server and transport implementations: it runs on the standard library's extremely-well-tested-and-high-performance net/http Server. It can run on HTTP 1.1, not just http/2, and supports JSON serialization for easy debugging.

Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data, think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. Protocol buffers currently support generated code in Java, Python, Objective-C, and C++. With our new proto3 language version, you can also work with Dart, Go, Ruby, and C#, with more languages to come. Package proto provides functions operating on protobuf messages such as cloning, merging, and checking equality, as well as binary serialization and text serialization. Package jsonpb serializes protobuf messages as JSON. Package ptypes provides helper functionality for protobuf well-known types.

jsonapi provides helpers and reference code for working with the JSON:API specification, focusing on predictable serialization, deserialization, and linkage of related resources. It enforces the spec’s conventions—data, attributes, relationships, included—so clients and servers exchange data in a consistent, cacheable way. By centralizing how resource identifiers, links, and pagination metadata are emitted, it reduces subtle incompatibilities between services. The library favors explicit schemas and type-safe bindings where possible, which helps large teams avoid drift in field names and relationship structures. It also offers utilities for sparse fieldsets and compound documents, minimizing payload size while keeping related entities synchronized. With consistent error objects and status mapping, it makes API error handling uniform across clients.