Jetty is an open-source web server and servlet container known for its scalability and efficiency, supporting protocols like HTTP and WebSocket for various applications from development tools to cloud services.
Websites Using Jetty
No websites detected yet. Analyze a website to contribute data.
What Is Jetty?
Jetty, maintained under the Eclipse Foundation as Eclipse Jetty, is an open-source Java web server and servlet container. It serves HTTP content and runs Java web applications built to the Servlet API, the same way a Java application running on Tomcat would. What distinguishes Jetty is its emphasis on being lightweight and embeddable: rather than only running as a standalone server you deploy applications into, Jetty is frequently embedded directly inside a Java application, so the application starts its own HTTP server in code rather than being dropped into an external one.
Jetty is widely regarded as one of the most established and respected Java servers, with a long history and broad adoption across the Java ecosystem. It is commonly used both as a standalone servlet container and, perhaps more notably, as an embedded server inside frameworks, tools, and products. It is not a framework, not a programming language, and not a browser extension; it is server infrastructure that handles HTTP, WebSocket, and servlet workloads for Java applications.
A servlet container (also called a web container) is the piece of software that implements the Java Servlet specification: it manages the lifecycle of servlets, maps incoming HTTP requests to the right servlet, handles sessions, and provides the runtime environment Java web applications expect. Jetty provides exactly this, along with support for modern protocols and APIs. Because it is modular and small, Jetty can be configured with only the components an application needs, which keeps its footprint low.
It helps to understand Jetty's dual identity. On one hand it is a capable standalone server that can host Java web applications packaged as WAR files, similar to Apache Tomcat. On the other hand, and this is where it especially shines, it is an embeddable library: a developer can add Jetty to a Java project and, in a few lines of code, start an HTTP server inside their own application process. This embeddable nature is why Jetty quietly powers the HTTP layer of many Java tools, build systems, big-data components, and microservices, often without end users ever realizing Jetty is involved.
How Jetty Works
Jetty is built around a modular architecture. At its core is a Server instance to which you attach Connectors (which accept network connections and speak protocols like HTTP/1.1, HTTP/2, and HTTPS) and Handlers (which process requests). This separation lets Jetty be assembled to taste: a minimal embedded server might use a single connector and a simple handler, while a full deployment layers in servlet handling, session management, security, and more.
The servlet container functionality implements the Java Servlet API, so applications written to that standard run on Jetty without modification. Jetty manages servlet lifecycles, request routing, filters, listeners, and HTTP sessions, providing the runtime contract Java web apps rely on. It supports deploying standard WAR-packaged web applications when used as a standalone server, and it can serve static content, JSP, and dynamic servlet-generated responses.
Jetty's embeddable model is central to its identity. A developer can write Java code that creates a Server object, configures a connector on a chosen port, registers handlers or servlets, and calls start(), all inside their own application. This means the application and its HTTP server share a single process, which simplifies packaging and deployment, an approach that fits microservices and self-contained "executable JAR" deployments especially well. Many higher-level frameworks offer Jetty as a pluggable embedded server option, letting teams choose Jetty in place of other containers.
On the protocol side, Jetty supports modern web standards, including HTTP/2, WebSocket, and asynchronous request handling. Asynchronous and non-blocking I/O let a relatively small number of threads handle many concurrent connections efficiently, which matters for high-concurrency and long-lived-connection workloads such as WebSocket-based applications. Jetty's connection handling and thread-pool model are designed to scale without excessive resource use.
When a request arrives, a connector accepts the connection and parses the HTTP request, the server routes it through the configured handler chain (which may include security, session, and servlet handlers), the appropriate servlet or handler produces a response, and the connector writes it back to the client. In production, Jetty is often deployed behind a reverse proxy or load balancer that terminates TLS and distributes traffic, though Jetty is fully capable of handling HTTPS directly. A Java Virtual Machine hosts the whole thing, and operators tune the JVM and Jetty's thread pools to match their workload.
Because Jetty is frequently embedded, its presence is sometimes an implementation detail of a larger product rather than a deliberate "we chose a web server" decision. A build tool, an application server's admin console, a big-data cluster's web UI, or a developer tool's local dashboard may all be served by an embedded Jetty instance, which is part of why Jetty is so pervasive yet often unseen.
How to Tell if a Website Uses Jetty
Jetty can sometimes be identified from the outside through HTTP response signals, but as with most server-side software, those signals are frequently hidden behind a reverse proxy. StackOptic analyzes a URL from the server side and inspects the same response headers you can check manually, while recognizing the limits when traffic is proxied.
The Server response header. Jetty's most direct fingerprint is the HTTP Server header. When Jetty answers a request directly, it often sends Server: Jetty(<version>), for example Server: Jetty(9.4.x) or a similar string including the version. You can check this with curl -I https://example.com and read the Server line. The important caveat is that a fronting proxy such as Nginx, Apache, or a load balancer commonly overwrites or removes this header, so its absence does not rule Jetty out. Jetty can also be configured to suppress or customize the header for security reasons.
Session cookie names. Java servlet containers, Jetty included, use a session cookie conventionally named JSESSIONID. Seeing a JSESSIONID cookie strongly indicates a Java servlet container behind the site, which narrows the field to Jetty, Tomcat, or a similar container even when the exact one is not named. Our guide on how to find out what programming language a website uses explains how cookies and other signals point to a Java back end.
Error pages and behavior. Default Jetty error responses sometimes carry recognizable wording or formatting, though production sites usually replace these. This is a weak, supplementary signal at best.
| Method | What to do | What it may reveal |
|---|---|---|
| curl -I | Run curl -I https://example.com | A Server: Jetty(...) header when not proxied |
| View Source / DevTools | Check cookies in the Application/Storage panel | A JSESSIONID cookie indicating a Java servlet container |
| HTTP header reading | Inspect all response headers | Server name, version, proxy hints |
| Wappalyzer | Run the extension on the live page | May list Jetty or Java if signals are exposed |
| BuiltWith | Look up the domain | Possible Jetty or Java server detection |
A fast terminal check is curl -sI https://example.com | grep -i server, followed by inspecting cookies for JSESSIONID. For deeper guidance, see our articles on how to read a website's HTTP headers and how to find out what server software a website runs.
It is worth being clear about detection limits. Server-side software like Jetty is often invisible to outside observers, both because production deployments place a reverse proxy in front that rewrites the Server header, and because Jetty is so frequently embedded inside a larger product that its presence is an internal detail. When Jetty does expose its Server header, identification is straightforward; when that header is masked, the most useful evidence becomes the JSESSIONID cookie, which confirms a Java servlet container without naming which one. Distinguishing Jetty from Tomcat or another container then depends on whatever additional signals leak through, and sometimes the honest conclusion is "a Java servlet container, possibly Jetty" rather than a definitive answer. This is precisely why automated analysis weighs multiple clues together and reports a confidence level rather than relying on any single header that a proxy might have stripped.
Key Features
- Lightweight and modular. A small core with pluggable connectors and handlers, configured to include only what is needed.
- Embeddable. Can run as an HTTP server inside a Java application in a few lines of code, ideal for microservices and self-contained apps.
- Servlet container. Full Java Servlet API support for running standard Java web applications and WAR files.
- Modern protocols. HTTP/2, WebSocket, and asynchronous, non-blocking request handling.
- Scalable concurrency. A thread-pool and async I/O model that handles many connections with modest resources.
- Standalone or embedded. Deploy applications into a Jetty server, or embed Jetty inside your own.
- Mature and open source. A long-established Eclipse Foundation project with broad ecosystem adoption.
Pros and Cons
Pros
- Exceptionally lightweight and embeddable, making it a favorite for microservices and tooling.
- Strong support for modern protocols like HTTP/2 and WebSocket, with efficient async I/O.
- Modular design lets you include only the components your application needs.
- Mature, stable, and widely used across the Java ecosystem.
Cons
- As server infrastructure, it requires Java expertise to configure and tune effectively.
- Often embedded as an implementation detail, which can make it hard to identify from the outside.
- For purely standalone WAR hosting, some teams default to alternatives out of habit.
- Like any application server, it usually needs a reverse proxy in front for TLS offload and edge features in production.
Jetty vs Alternatives
Jetty competes with other Java servlet containers and embedded server libraries. The table below clarifies its positioning.
| Server | Model | Best for | Notes |
|---|---|---|---|
| Jetty | Servlet container, embeddable | Embedded servers, microservices, tooling | Lightweight, modular, modern protocols |
| Apache Tomcat | Servlet container | Standalone WAR hosting | The most ubiquitous Java container |
| Undertow | Embeddable web server | Reactive and embedded apps | Very lightweight, non-blocking core |
| WildFly / JBoss | Full Java EE server | Enterprise Jakarta EE apps | Broad spec support beyond servlets |
| Netty | Async network framework | Custom network protocols | Lower-level than a servlet container |
Jetty and Tomcat are the two names most often weighed against each other for servlet hosting; Jetty's edge is its embeddability and small footprint. Because Jetty runs Java applications, understanding the underlying platform is useful context; see our profile of the Java ecosystem for the language layer beneath the server.
Use Cases
Jetty's standout use case is as an embedded HTTP server inside Java applications. Microservices and self-contained applications bundle Jetty so the service starts its own HTTP listener and ships as a single executable artifact, simplifying deployment and scaling. This pattern is pervasive in modern Java backends, where each service is independently deployable.
Jetty also serves as the HTTP layer inside a wide range of Java tools and platforms. Build tools, administrative consoles, developer dashboards, and the web UIs of big-data and infrastructure components frequently embed Jetty to expose their interfaces over HTTP. In these cases Jetty is an implementation detail that quietly handles requests for a larger product. As a standalone server, Jetty hosts traditional Java web applications and WAR files where teams want a lighter alternative to a full application server.
Its strong WebSocket and asynchronous support make Jetty a good fit for real-time and high-concurrency workloads, such as messaging, live dashboards, and applications with many long-lived connections. For competitive and infrastructure research, identifying Jetty, or inferring a Java servlet container from a JSESSIONID cookie, signals a Java-based back end and an engineering organization invested in the JVM ecosystem. That is useful context for vendors selling Java tooling, observability, hosting, or enterprise services. Because Jetty is often embedded or proxied, analysts typically treat a confirmed Java container as the practical signal and combine it with other stack indicators, the kind of inference our guide on using tech-stack data to qualify leads describes.
Frequently Asked Questions
Is Jetty a web server or an application server?
Jetty is both a web server and a servlet container. It serves HTTP content like a web server and provides the Java Servlet runtime that Java web applications need, like an application server. Unlike heavyweight Java EE application servers, however, Jetty focuses on the servlet and web layer and stays lightweight, which is part of why it is so often embedded directly inside applications rather than run as a large standalone platform.
How do I know if a site runs on Jetty?
The most direct check is the HTTP Server header: run curl -I https://example.com and look for Server: Jetty(...), often with a version. If that header is missing because a reverse proxy has overwritten it, look for a JSESSIONID cookie, which indicates a Java servlet container (Jetty, Tomcat, or similar) without naming the exact one. Detection tools like Wappalyzer and BuiltWith may also flag Jetty when its signals are exposed.
What is the difference between Jetty and Tomcat?
Both are Java servlet containers that run the same standard Java web applications, so they overlap heavily. The main differences are in design emphasis: Jetty is especially lightweight and built to be embedded inside other applications with minimal code, while Tomcat is the most ubiquitous standalone container and is very commonly used to host WAR files directly. Many teams choose Jetty when they want an embedded server and Tomcat when they want a familiar standalone one.
Why is Jetty often hard to detect?
Two reasons. First, in production Jetty usually sits behind a reverse proxy that terminates TLS and overwrites the Server header, hiding Jetty's most obvious fingerprint. Second, Jetty is frequently embedded inside a larger product, so its presence is an internal implementation detail rather than something the public site advertises. As a result, outside detection often confirms only that a Java servlet container is present, with Jetty as one likely candidate.
Can Jetty handle HTTP/2 and WebSocket?
Yes. Jetty supports modern web protocols including HTTP/2 and WebSocket, along with asynchronous, non-blocking request handling. Its efficient thread-pool and I/O model let it handle many concurrent and long-lived connections with modest resources, which makes it well suited to real-time applications. These capabilities are a key reason developers choose Jetty for high-concurrency and WebSocket-heavy workloads.
Want to identify the server software and language behind any website? Run a URL through StackOptic at https://stackoptic.com.