hyper: the low-level HTTP engine behind Rust's web stack

What hyper is for, and who should not reach for it

hyper sits below the level most Rust web code is written at. The README describes it as "a relatively low-level library, meant to be a building block for libraries and applications", and that sentence is the whole positioning. It gives you HTTP/1 and HTTP/2, an asynchronous design, and both client and server APIs. It does not give you routing, middleware, extractors, JSON handling or a request builder with a nice ergonomic surface.

The intended audience is people writing the layer that others call: an HTTP client inside a database driver, a proxy, a gateway, a custom server that needs control over connection lifecycle. The repository layout reflects this. There is a src/ tree, a capi/ directory for a C API, benches/, and an examples/ folder with files such as client.rs, echo.rs, gateway.rs, http_proxy.rs, graceful_shutdown.rs and upgrades.rs. Those names describe HTTP-level concerns, not application concerns.

If you are building an ordinary web service and you want to define routes and handlers, hyper is the wrong entry point. The README says so directly: for a convenient HTTP client, consider reqwest; if you are not sure what HTTP server to choose, consider axum or warp, "the latter taking a more functional approach. Both are built on top of this library." Choosing hyper when you wanted axum means writing the parts axum already wrote.

The mechanism: a small core with optional protocol pieces

The dependency list in Cargo.toml shows how the library is assembled. A handful of crates are unconditional: bytes, http, http-body and tokio with only the "sync" feature enabled. Everything else is optional. h2 is optional, and that is the HTTP/2 implementation. httparse, httpdate and itoa are optional, which is what you would expect from an HTTP/1 parser and header formatting path. http-body-util, want, atomic-waker, futures-channel, futures-core, futures-util, pin-project-lite, smallvec and tracing are all optional too.

That structure has a practical consequence: a default build is not the same as a build with HTTP/2 and the higher-level body utilities. You opt into the pieces you use. It also explains why the crate can stay small while serving both client and server roles; the protocol machinery is pulled in per feature rather than shipped wholesale.

The runtime coupling is deliberately thin. hyper depends on tokio for the "sync" feature only, not for the whole runtime. The examples include single_threaded.rs, which is a signal that the library does not assume a multi-threaded executor for you. The async design is the point: connections, request bodies and response bodies are futures and streams that you drive, and the README's claim of an "asynchronous design" is the architectural commitment rather than a feature bullet.

Installing hyper and running a first server

hyper is published on crates.io and is added as a normal Cargo dependency. The Cargo.toml in the repository declares the package name as hyper and the current version as 1.11.1, so a dependency line without a version pin resolves to the 1.x line. The declared minimum supported Rust version is 1.63, written in Cargo.toml with the comment that it must be kept in sync with the MSRV.md development document.

Add it to your project manifest. The Cargo.toml in the repository declares the package name and version exactly as shown here, and the README's get-started link points at the 1.x guides:

[package]
name = "hyper"
version = "1.11.1"

Because the protocol and utility pieces are optional, a real server build usually enables features as well. The exact feature names are defined in Cargo.toml's optional dependency entries, and the guides at hyper.rs/guides/1/ are where the project sends readers for the current recommended set.

The fastest way to see a working request/response cycle is to read one of the shipped examples rather than write one from scratch. The examples directory contains hello.rs, which is the minimal server, and client.rs, which is the minimal client. The dev-dependencies in Cargo.toml show what those examples are built against:

[dev-dependencies]
form_urlencoded = "1"
futures-channel = { version = "0.3", features = ["sink"] }
futures-util = { version = "0.3", default-features = false, features = ["alloc", "sink"] }
http-body-util = "0.1"
pretty_env_logger = "0.5"
pin-project-lite = "0.2.4"
spmc = "0.3"

What you should take from that block is that the examples are ordinary Cargo targets compiled against the crate's own manifest, so they use the same feature set the maintainers test against. The examples are listed in examples/README.md, which is the file to read for what each one demonstrates. For a client-only starting point, examples/client_json.rs shows a JSON request and response; for HTTP/2 specifically, examples/hello-http2.rs is the one to open. Read the example before adapting it, because the body types and the executor setup are the parts that differ most from framework code.

Where hyper will cost you time

The honest limitation is the one the README states: this is a building block, and building blocks leave gaps. There is no router in the crate. There is no middleware chain. There is no built-in TLS story in the dependency list; the optional dependencies cover HTTP/2, parsing, dates, integer formatting, futures plumbing and tracing, and nothing in that list is a TLS implementation. If you need HTTPS, you are choosing and wiring a TLS layer yourself, or you are using a crate that already did.

A second cost is the feature surface. Because so much is optional, a build that compiles does not tell you whether you enabled the right combination for HTTP/2 or for the body utilities. That is a configuration burden that higher-level crates hide from you.

There is also a versioning boundary worth noting. hyper 1.x is a different API generation from the 0.14 line that much of the older Rust web ecosystem was written against, and the README's get-started link points specifically at the 1.x guides. Code samples and blog posts written for 0.x do not transfer directly. If you are maintaining something pinned to the older line, the upgrade is a migration, not a version bump.

Finally, the C API under capi/ exists, but the README does not document it as a supported surface for new users. Treat it as a specialised entry point rather than the normal way in.

hyper versus reqwest, axum and warp

The README names the alternatives itself, and the difference is one of altitude. reqwest is the convenient HTTP client: if your goal is to make requests and get responses with a usable API, reqwest is the layer above hyper and the README recommends it for exactly that. Choosing hyper for a client means you want control over connection handling, protocol selection or body streaming that a convenience client abstracts away.

On the server side, axum and warp are the two the README points to, and both are built on hyper. axum is described in the README only by name, but the framing is clear: it is the option for people who want a server framework rather than a protocol library. warp is called out as taking "a more functional approach", which is the distinguishing note the README gives. The practical difference is that with axum or warp you write handlers against a router; with hyper you write the service that the router would have produced, and you own connection acceptance, shutdown and upgrade handling.

That ownership is not a downside for everyone. examples/graceful_shutdown.rs and examples/upgrades.rs exist precisely because those behaviours are yours to implement at this level, and a framework that hides them also hides the hooks you might need.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-18. Recent releases are v1.10.1 on 2026-05-29, v1.11.0 on 2026-07-20 and v1.11.1 on 2026-08-28. That is a steady release cadence on the 1.x line, and the version numbers suggest patch releases are used for fixes within the minor line rather than holding them for a larger bump.

Upgrade cost is concentrated at the major boundary. Within 1.x, the Cargo.toml version of 1.11.1 and the dependency example of hyper = "1" indicate that the project treats the 1.x series as compatible. The expensive move is from 0.14 to 1.x, where the API changed enough that the project publishes separate 1.x guides. Budget for that as a rewrite of your HTTP layer, not a dependency edit.

Licensing is simple to state and not simple to advise on. The crate is MIT licensed, declared in both Cargo.toml and the README, with the full text in the LICENSE file. MIT is permissive and imposes no copyleft obligation on your own code. That is the fact; what it means for your specific distribution and attribution requirements is a question for your own legal review, not something this article can settle.

Editorial conclusion

Adopt hyper if you are writing a client or server layer that other code will sit on, or if you need HTTP/2 and connection handling without a framework's opinions. Do not adopt it if you want routing, extractors or a batteries-included request builder; the README points those users at reqwest for clients and axum or warp for servers. Before committing, read the guides at hyper.rs/guides/1/ and open the example that matches your shape (examples/client.rs, examples/hello.rs), then confirm the MSRV of 1.63 and the optional feature flags you actually need, because a default build does not include HTTP/2 or the server pieces.

Frequently asked questions

Official sources

1. hyperium/hyper on GitHub
2. License: MIT
3. Project website
4. README
5. Releases