ijl/orjson

Fast, correct Python JSON library supporting dataclasses, datetimes, and numpy

View on GitHub ↗Jump to charts ↓

Summary Information

Updated 59 minutes ago
Added to GitGenius on September 8th, 2026
Created on November 21st, 2018
Open Issues & Pull Requests: 0 (+0)
GitHub issues: Disabled - open counts may still include pull requests.
Number of forks: 335
Total Stargazers: 8,227 (+0)
Total Subscribers: 37 (+0)

Repository Insights (GitGenius)

Most active contributors

Sign in to see contributor activity.

Related repositories by overlapping contributors

No overlapping-contributor repos identified yet.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

GitHub issues are disabled for this repository, so issue analytics and the issue explorer are not available.

Detailed Description

orjson is a fast JSON serialization and deserialization library for Python built in Rust.

The library addresses the need for high-performance JSON handling in Python by implementing core serialization and deserialization logic in Rust via PyO3 bindings. It achieves substantially faster performance than the standard library json module and other third-party alternatives, with serialization roughly ten times faster and deserialization roughly two times faster. The tool natively handles dataclasses, datetime objects, numpy arrays, and UUID instances without requiring custom serializers, while also providing a default parameter for caller-specified handling of arbitrary types and flags to control output formatting.

Developers should adopt orjson when performance is a priority in JSON-heavy workloads, particularly those involving scientific computing with numpy or applications using dataclasses and datetime objects extensively. The library is production-ready for CPython 3.10 and later across major platforms and architectures, with optimized wheels that take advantage of AVX-512 instructions when available. The tool deliberately does not provide file I/O or line-delimited JSON handling, so projects requiring those conveniences should handle them separately. The project does not support PyPy, embedded Python builds, or PEP 554 subinterpreters, and maintains strict semantic versioning where serializing new object types requires an explicit opt-in flag to avoid breaking changes.

Development activity shows a conservative, stability-focused approach. The maintainer does not maintain an open issue tracker or accept pull requests, citing signal-to-noise ratio concerns. The project publishes a detailed changelog documenting all changes. The tool may support PEP 703 free-threading when that specification becomes stable, indicating willingness to adopt new Python features once they reach maturity.