nghttp2: the C library, client, server and proxy behind a lot of HTTP/2 traffic
nghttp2 - HTTP/2 C Library and tools
At a glance
- What is it?
- nghttp2 is a C implementation of HTTP/2 framing, plus the nghttp, nghttpd, nghttpx and h2load programs built on top of it. It is a good fit when you need HTTP/2 at the protocol level, and the wrong tool when you just want a web server.
- Who is it for?
- Adopt nghttp2 if you are writing an HTTP/2 client, server, proxy or load generator and want the framing layer as a library rather than a full web framework. Do not adopt it if you want a general purpose web server or an HTTP/1.1 stack.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 14, 2026, and from our analysis. They are not legal advice.
Star history
- nghttp2/nghttp25,075 ★ · +20
| Repository | 2026-09-23 | 2026-11-14 |
|---|---|---|
| nghttp2/nghttp2 | 5.1k | 5.1k |
20 Stars in the last 52 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
What nghttp2 actually provides, and who needs it
The repository describes itself as an HTTP/2 C library and tools. That is the centre of the project. Everything else is built on it: an HTTP/2 client (nghttp), a server (nghttpd), a proxy (nghttpx) and load test and benchmarking tools (h2load). An HPACK encoder and decoder are exposed as a public API as well.
The intended audience is people who need HTTP/2 at the framing level rather than through a web framework. If you are writing a client that has to speak h2 or h2c directly, or a proxy that terminates HTTP/2 and forwards it, the library gives you the frame handling and HPACK without dictating your I/O model.
The framing layer, HPACK, and where the applications sit
The architecture is layered. libnghttp2 handles HTTP/2 framing and HPACK; the applications in src/ (nghttp, nghttpd, nghttpx, h2load) sit on top.
Installing nghttp2 and making a first request
The build is autotools-based (configure.ac, Makefile.am) with a CMakeLists.txt also present at the top level.
nghttpx is configured through a sample file in the repository, nghttpx.conf.sample, which is the reference point for its options rather than the README prose.
Build options that change the security and memory profile
The repository carries a bpf/ directory and an nghttpx.conf.sample file at the top level; the README points to README.rst for the documentation.
Where nghttp2 is the wrong choice
The clearest limitation is scope. nghttp2 is an HTTP/2 implementation with tools attached; it is not a general purpose web server with a module ecosystem, a configuration language for application routing, or a request lifecycle for application code. If your problem is serving a web application, nghttpx is a reverse proxy, and reaching for it as an origin server means writing your own logic against a tool that was not designed for it.
nginx, curl and the difference between embedding and terminating
The realistic alternative depends on what you are doing. If you need a server that terminates HTTP/2 for a website, nginx is the obvious comparison, and the difference is structural: nginx is a full HTTP server where HTTP/2 is one protocol among several, configured through its own directive set. nghttp2 gives you the framing layer and a proxy, and leaves request handling to you. Choosing nghttp2 for a website means choosing to write the application layer yourself.
If you need a client, curl already speaks HTTP/2 and is built against nghttp2 in many distributions. The distinction is that curl is an application, while nghttp2's public API lets you drive the connection from inside your own program, including the HPACK encoder and decoder. If you only need to fetch URLs, curl is the shorter path; if you need to embed HTTP/2 in a program you control, that is what the library is for.
There is also an HTTP/3 split worth naming. nghttp3 is a separate project. nghttp2 handles HTTP/2 framing; HTTP/3 framing lives in nghttp3. They are not interchangeable, and the presence of nghttp2 in a dependency list does not imply HTTP/3 capability.
Maintenance, licence and upgrade cost
The repository is not archived, and the last push was on 2026-11-02. Releases are frequent: v1.71.0 on 2026-11-02, v1.70.0 on 2026-07-29, v1.69.0 on 2026-04-19. A project shipping releases at that cadence with a recent push is being worked on.
The licence is MIT, and the repository carries a COPYING file at the top level.
The go.mod file at the top level declares Go 1.26.0 and pulls in quic-go, gomemcache and golang.org/x/net, which indicates Go components in the repository that are separate from the C library.
Editorial conclusion
Adopt nghttp2 if you are writing an HTTP/2 client, server, proxy or load generator and want the framing layer as a library rather than a full web framework. Do not adopt it if you want a general purpose web server or an HTTP/1.1 stack. Before adopting, read README.rst, which the README points to, and nghttpx.conf.sample for the proxy options.
Frequently asked questions
What is nghttp2?
It is an implementation of HTTP/2 in C. The framing layer is a reusable C library, and on top of it the project provides an HTTP/2 client, server and proxy, plus load test and benchmarking tools, with an HPACK encoder and decoder available as a public API.
What is nghttp2 dll?
The README only points to README.rst; the top level carries configure.ac and CMakeLists.txt for autotools and CMake builds.
nghttp2 vs nghttp3: what is the difference?
nghttp2 implements HTTP/2 framing and HPACK. nghttp3 is a separate project. They are not interchangeable.
Official sources
Was this useful?