Express.js

What Is Express?

Express, often written Express.js, is a minimal and flexible web application framework for Node.js. It provides the routing and middleware layer that turns Node's low-level HTTP capabilities into a practical foundation for building web servers and APIs. If you want the short answer, Express is the thin, unopinionated framework most Node.js backends are built on, the layer that decides how incoming requests map to your code and how responses are produced. Crucially, Express is a server-side framework. Unlike Nuxt, Gatsby, or Svelte, it has no presence in the browser, which makes it fundamentally harder to detect from the outside.

Express is open source and was created by TJ Holowaychuk. It is widely described, including in its own documentation, as a "fast, unopinionated, minimalist web framework for Node.js," and it has long been the de facto standard for Node web development. Exact usage figures vary by source and detection method, and because Express runs on the server its real footprint is systematically undercounted by tools that inspect only client-side code, so treat any single percentage with extra caution here. What is not in dispute is that Express is one of the most depended-upon packages in the Node ecosystem and underpins or inspires many higher-level frameworks.

You will find Express behind a huge range of backends: REST and JSON APIs, server-rendered web apps, proxies, and the server half of full-stack JavaScript applications.

How Express Works

Express is built around two core concepts: routing and middleware. Almost everything Express does is an expression of these two ideas.

Routing maps a combination of HTTP method and URL pattern to a handler function. A route says, in effect, "when a GET request arrives for /users/:id, run this function." Route parameters (the :id part) extract dynamic values from the URL, and Router instances let you group related routes into modular, mountable units. This is how an Express application organizes the surface area of its API.

Middleware is the defining characteristic. A middleware function receives the request object, the response object, and a next function, and it sits in a pipeline that each request flows through in order. Each middleware can inspect or modify the request, write to the response, or pass control to the next function in the chain by calling next(). This composable pipeline is how Express handles concerns like body parsing, authentication, logging, compression, CORS headers, and error handling, each as a separate, swappable middleware. Common packages plugged into this pipeline include body-parsing middleware, cors for cross-origin requests, helmet for security headers, logging middleware, and authentication middleware such as Passport.

Because Express is minimalist and unopinionated, it ships only this essential request/response machinery and leaves architectural decisions, folder structure, database choice, validation strategy, to the developer. That flexibility is why Express is everywhere and also why two Express apps can look nothing alike internally.

Express supports server-side templating through view engines like Pug, EJS, and Handlebars, so it can render HTML directly. In practice, however, a large share of modern Express apps act as API backends that return JSON to a separate frontend (often a React, Vue, or Svelte single-page app). This matters for detection: when Express is purely a JSON API behind a separate frontend, almost nothing about Express reaches a human browsing the site.

The key takeaway is architectural: Express produces responses, but it does not, by itself, stamp those responses with an obvious "made with Express" marker. Whatever fingerprints exist are subtle, optional, and easy to remove.

How to Tell if a Website Uses Express

Detecting a server-side framework is inherently harder than detecting a client-side one, because the framework's code never reaches the browser. Express leaves only faint, often-suppressed traces. Here is what to look for, with appropriate caveats.

1. The X-Powered-By: Express response header. Historically, Express adds an X-Powered-By: Express header to responses by default. When present, this is a direct confession that the backend is Express. The important caveat: it is trivially disabled (a single line, app.disable('x-powered-by')), and security-conscious teams routinely turn it off. So the header confirms Express when it appears, but its absence proves nothing.

2. The connect.sid session cookie. Express applications that use the common express-session middleware (built on Connect) set a session cookie named connect.sid by default. Spotting a connect.sid cookie in the response is a strong hint that the backend is an Express/Connect stack. As with the header, the cookie name can be customized, so it is suggestive rather than definitive.

3. Default error pages. When an Express app hits an unhandled route or error and is not running in production hardening mode, it can return recognizable default responses, for example a plain Cannot GET /some-path message for an unmatched route, or a stack-trace-style HTML error page. These default formats are characteristic of Express and can betray the framework when error handling has not been customized.

4. Behavioral and stack hints. Other Node/Express signals include ETag header formatting typical of Express, JSON error shapes from common middleware, and the broader observation that the server is running Node.js at all. None of these is conclusive on its own, but together they raise or lower confidence. The honest framing is probabilistic: detecting Express from outside is a matter of accumulating weak signals rather than finding one definitive marker, which is the opposite of the situation with client-side frameworks like Svelte or Gatsby that broadcast themselves in the DOM. A site can run Express and present no external evidence at all once headers are stripped and a reverse proxy normalizes responses.

5. Tooling. Given how easily the signals are suppressed, the right tools focus on headers and responses rather than client code:

• View Source is the least useful here, because Express leaves little or nothing in the rendered HTML of an API-backed site; it helps only when Express is rendering server-side templates.
• Browser DevTools (the Network tab, then inspecting an individual request's Response Headers and Cookies) is the primary manual method, this is where X-Powered-By and connect.sid show up.
• Wappalyzer and similar extensions will report Express when the telltale header or cookie is present, but will simply miss it when those are disabled.
• A server-side analyzer such as StackOptic fetches the response and reads its headers directly, which is the most practical way to catch header- and cookie-based signals.

Because so much hinges on response headers, the methodology in how to read a website's HTTP headers is the most relevant companion here. Detecting a backend framework is really a special case of how to find out what programming language a website uses, since identifying Node.js is often the first step toward suspecting Express. For the wider stack, how to find out what technology a website uses ties the server and client signals together.

Key Features

• Minimalist core that provides routing and middleware without imposing structure.
• Middleware pipeline for composable request processing, parsing, auth, logging, CORS, security headers, and error handling.
• Flexible routing with HTTP-method matching, route parameters, and modular Router instances.
• View-engine support for server-side templating with Pug, EJS, Handlebars, and others.
• Vast ecosystem of compatible middleware packages for nearly any need.
• Unopinionated design that lets teams architect applications to their own preferences.
• Foundation for higher-level frameworks that build on or imitate its patterns.

Pros and Cons

Strengths	Trade-offs
Minimal, flexible, and easy to learn	Unopinionated, so teams must impose their own structure
Enormous ecosystem of middleware	Little built-in guidance on architecture or validation
Battle-tested and extremely widely deployed	Callback/middleware style can feel dated next to newer frameworks
Works for both APIs and server-rendered apps	Minimal core means more assembly for large apps
Easy to deploy on any Node host	Server-side nature makes it hard to detect and audit externally

For most Node backends, Express's flexibility is the point; the cost is that you make more decisions yourself.

Express vs Alternatives

Framework	Style	Opinionatedness	Notable trait
Express	Minimal middleware	Low	The de facto Node standard
Fastify	Minimal, performance-focused	Low	Schema-based, high throughput
Koa	Minimal, modern async	Very low	From the Express team; uses async middleware
NestJS	Structured, opinionated	High	TypeScript, often runs on top of Express
Hapi	Configuration-centric	Medium	Built-in validation and config

Several of these are not pure competitors: NestJS frequently uses Express as its underlying HTTP layer, and Koa comes from Express's own authors as a more modern take. The choice usually comes down to how much structure you want, Express for maximum flexibility, NestJS for enforced conventions, Fastify when raw performance is the priority.

Use Cases

• REST and JSON APIs that serve a separate frontend or mobile app, the most common Express deployment today.
• Server-rendered web applications using a view engine like Pug or EJS.
• The backend half of full-stack JavaScript apps, paired with a React, Vue, or Svelte frontend.
• Proxies, gateways, and middleware layers that sit in front of other services.
• Prototypes and microservices where a lightweight, quick-to-stand-up server is ideal.

A pattern worth highlighting is that Express's invisibility cuts both ways for these use cases. As a pure JSON API behind a single-page app, Express is almost undetectable from the browser, which is fine operationally but means external audits will usually identify the frontend framework and the hosting provider while the backend stays a question mark. As a server-side-rendering app using a view engine, Express leaves slightly more to work with, since it is producing the HTML you see, though even then it does not stamp the markup with an obvious signature the way client-side frameworks do. The practical consequence is that any confident Express identification leans on response headers and cookies rather than page content.

Because Express is invisible from the browser, confirming it is part of a stack usually means combining a header/cookie check with language detection; the workflow in how to find out what programming language a website uses is the natural starting point.

Want to inspect a site's response headers and backend hints without opening DevTools? Analyze any URL with StackOptic.

Frequently Asked Questions

Why is Express hard to detect from outside?

Because it runs entirely on the server. Express's code never reaches the browser, so there are no DOM markers, global variables, or asset paths to inspect, the kinds of signals that make client-side frameworks easy to spot. The only external clues are response headers, cookies, and occasional default error pages, all of which can be disabled or customized.

Does the absence of an X-Powered-By header mean the site is not using Express?

No. The X-Powered-By: Express header is on by default but is commonly disabled for security reasons with a single configuration line. Its absence is therefore inconclusive; a site can absolutely be running Express without advertising it in headers.

What does a connect.sid cookie tell me?

A connect.sid cookie is the default session-cookie name used by the popular express-session middleware, which is built on Connect (the middleware layer Express descends from). Seeing it strongly suggests an Express/Connect backend, though the cookie name can be customized, so treat it as a strong hint rather than proof.

Is Express the same as Node.js?

No. Node.js is the JavaScript runtime that executes server-side code. Express is a framework that runs on top of Node.js to provide routing and middleware. Detecting Node.js (for example, via certain headers or behavior) is often the first step, and suspecting Express comes after, once Express-specific signals like the header or cookie appear.

Can a site use Express together with a frontend framework like React?

Yes, and it is extremely common. A typical full-stack setup uses Express as a JSON API on the server and React, Vue, or Svelte in the browser. In that arrangement you would detect the frontend framework easily from client-side signals, while Express stays hidden on the backend unless its headers or cookies give it away.