cJSON

Ultralightweight JSON parser in ANSI C

Languages & Compilers Data & Databases

Explore on GitHub Read Hacker News discussions

9Distinct people

9Mentions

1Explicit recommenders

13.1KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Ultralightweight JSON parser in ANSI C

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

Did you try cJSON? Works well for me. https://github.com/DaveGamble/cJSON

alex_suzuki used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year9 dated mentions

Observed mentions: 2019-01-06 18:11:18 UTC to 2025-09-21 20:50:41 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	0	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	4	0	4
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	1	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	1	0	1
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	2	0	2

What Hacker News says

4 sources

FSMaxB·Nov 24, 2020

My statement: https://github.com/DaveGamble/cJSON/commit/65541b900c740e1d5... At some point I have realised, that just letting cJSON be the horror of a codebase it was before I started maintaining it would have been the best thing to do, but that's what you call hindsight. At least now I know. One reason I burned out was because I felt horrified by how many people are using cJSON and felt a responsibility to make it better and safer for all of them, even though I myself haven't ever been really using it. The combination of this mounting pressure plus the the impossible fight against semantic versioning and memory unsafety gave me the rest. By improving it, but being unable to completely "fix" it, I probably led more people to use it, making the situation even worse than it was before.

In “To be safe allocate 5 bytes more than you need”

Znafon·Nov 23, 2020

The Pull Request is at https://github.com/DaveGamble/cJSON/pull/146

In “To be safe allocate 5 bytes more than you need”

avian·Nov 23, 2020

Some more clues where this comes from are in this issue: https://github.com/DaveGamble/cJSON/issues/255

In “To be safe allocate 5 bytes more than you need”

cbsks·Nov 23, 2020

I abhor comments like these. It says that it needs to allocate 5 more bytes, and I can see that in the code, but it doesn't say why the magic number is 5. The comment explains the what but not the why. The commit message is equally as useless: https://github.com/DaveGamble/cJSON/commit/65541b900c740e1d5... What needs to be fixed so that this "+5" can be removed? What happens if something changes and the magic number needs to be 6? Also, where's the unit test?

In “To be safe allocate 5 bytes more than you need”