How to Tell if a Website Is Built with Ruby on Rails

If you want to know whether a website is built with Ruby on Rails, the clearest answer is to look in the page head and forms for Rails' CSRF markers — a csrf-token meta tag and an authenticity_token hidden field — plus a session cookie ending in _session (often appname_session). As with any server-side framework, the catch is that Rails runs in Ruby on the server and returns finished HTML, so it leaves far fewer client-side traces than a JavaScript framework. You detect it from its side effects: cookies, the CSRF meta tag, fingerprinted asset filenames, and characteristic response headers. This guide walks through every signal, how to read it with View Source, the DevTools Application tab or a single curl -I, and the caveat that a CDN or custom config can hide the tells.

It sits alongside the broader how to find out what technology a website uses and the language-focused how to find out what programming language a website uses, since Rails is the most common way a site turns out to be a Ruby application.

What Ruby on Rails is, briefly

Ruby on Rails is a popular open-source web framework written in Ruby, famous for its "convention over configuration" philosophy and for popularising rapid, opinionated web development. It provides an ORM (Active Record), a templating layer, routing, an asset pipeline, and strong built-in security defaults — including automatic cross-site request forgery protection. Because it is server-side, the work happens on the host: a request arrives, Rails' Ruby code runs, queries the database, renders a view, and returns HTML. The browser never downloads "Rails" the way it downloads a React bundle. That shapes detection — you are looking for the traces a Ruby server leaves: the session cookie, the CSRF meta tag and form token, the fingerprinted asset filenames, and the headers Rails adds. Rails' conventions are strong and consistent, which is exactly what makes those traces recognisable.

Why server-side frameworks are harder to detect

Stating the limitation up front explains the method. A client-side framework is loud: named JavaScript chunks, an inlined data blob, known DOM mount points — all visible in View Source and the Network tab. A server-side framework like Rails is quiet: the HTML it returns is just HTML, with no framework-branded asset for the browser to fetch. So instead of reading the framework directly, you read the evidence of how the page was produced. The good news with Rails specifically is that its security defaults force a couple of markers into the client-visible HTML — the csrf-token meta tag and the authenticity_token field — which makes Rails a little easier to spot than some server-side frameworks. The rest of the signals follow the usual "read the side effects" pattern that powers programming-language detection for server-side stacks.

Signal 1: the CSRF meta tag and authenticity_token (the best tell)

Rails' cross-site request forgery protection produces its most reliable client-visible signals. On rendered pages, Rails injects a meta tag into the head that looks like <meta name="csrf-token" content="..."> (usually paired with <meta name="csrf-param" content="authenticity_token">). And in HTML forms, Rails inserts a hidden authenticity_token field. Rails' JavaScript reads the meta tag to attach the token to non-GET requests. This pairing — a csrf-token meta tag in the head plus an authenticity_token field in forms — is highly characteristic of Ruby on Rails. To check, View Source (Ctrl/Cmd + U) and search for csrf-token and authenticity_token. Finding both is a strong, near-definitive Rails signal, because they are baked into how the framework secures form submissions and are hard to remove without breaking that protection.

Signal 2: the session cookie

Rails sets a session cookie whose name, by convention, ends in _session — frequently the application name plus _session (for example myapp_session), and historically _session_id. To check, open DevTools (F12), go to the Application tab, expand Cookies, and read the cookie names for the domain; you can also catch it from curl -I in the Set-Cookie header. A cookie ending in _session, especially alongside the CSRF meta tag, reinforces a Rails identification. The name is configurable, so a custom session cookie name does not rule Rails out — but the _session suffix appearing is a clear supporting positive. As always, presence is stronger evidence than absence, since the cookie may only be set once a session begins.

Signal 3: fingerprinted /assets/ filenames

Rails' asset pipeline has a distinctive habit: it serves compiled CSS and JavaScript from an /assets/ path with a content hash in the filename, producing names like application-9a8b7c6d....js and application-<hash>.css. The hash is for cache-busting — when the file changes, the name changes. When you View Source or watch the Network tab, links to /assets/application-<long-hash>.css and similar are a Rails-flavoured hint. The /assets/ path alone is not unique to Rails, but the specific pattern of a named bundle (application) with a long content hash is characteristic of the Rails asset pipeline (Sprockets, and in newer setups Propshaft or jsbundling). Weight it as solid corroboration alongside the CSRF markers.

Signal 4: response headers

Headers can corroborate. Many Rails apps send an X-Request-Id header (a per-request identifier Rails uses for logging and tracing), and you may see an ETag and Rails-style caching headers. Rails does not advertise its name in a default response header, and X-Powered-By is uncommon for Ruby stacks, so headers are supporting rather than definitive here. The web server in front — often Puma as the application server, behind nginx — may surface in the Server header, pointing to a Ruby deployment consistent with Rails. Reading these well is its own skill; see how to read a website's HTTP response headers for the full technique. Treat an X-Request-Id plus the CSRF markers as a coherent Rails combination.

Signal 5: the 422 page and default error pages

Rails has recognisable error behaviours. Its default response to a failed CSRF check is 422 Unprocessable Entity, a status code Rails uses prominently — so a 422 in certain flows is a Rails-flavoured hint. Older Rails apps also shipped instantly recognisable default 404 and 500 pages ("The page you were looking for doesn't exist" on a plain white page). Modern apps almost always customise these, so do not rely on them, and never deliberately try to break a site to provoke an error. But if you happen to see a stock Rails error page or a 422 where a CSRF check failed, it is a useful corroborating signal.

The signal table

Signal	Where to find it	What it means
<meta name="csrf-token">	View Source (head)	Rails CSRF meta tag — strong
authenticity_token hidden field	View Source (forms)	Rails CSRF form token — strong
Cookie ending in _session	DevTools Application, Set-Cookie	Rails session cookie — supporting
/assets/application-<hash>.css/js	View Source, Network tab	Rails asset pipeline fingerprinting — supporting
X-Request-Id header	Response headers	Common Rails request header — supporting
422 Unprocessable Entity	Failed CSRF / certain flows	Characteristic Rails status — supporting
Stock Rails 404/500 page	A broken page (older apps)	Legacy Rails default — corroborating when seen

The CSRF meta tag plus the authenticity_token field alone make a strong call; add a _session cookie or fingerprinted assets and it is confident.

Method 1: View Source

The single best check for Rails is View Source, because the framework's strongest markers are right in the HTML. Open the page, press Ctrl/Cmd + U, and search for csrf-token and authenticity_token. Finding the meta tag in the head and the hidden field in a form is a strong Rails signal on its own. While you are there, scan the asset links for the /assets/application-<hash> pattern. Because Rails puts the CSRF meta tag directly into server-rendered HTML, a static source view catches it reliably — which is why this method leads for Rails specifically.

Method 2: the DevTools Application and Network tabs

For the cookie and header signals, use DevTools. Open it (F12), go to the Application tab, and read the Cookies for a name ending in _session. Then switch to the Network tab, reload, click the main document request, and read the Response Headers for Set-Cookie, X-Request-Id and the Server value; note the /assets/ fingerprinted files in the request list. This live view confirms the cookie and surfaces the headers that corroborate the CSRF-tag finding from View Source.

Method 3: curl -I from the terminal

For a fast, scriptable check, curl -I https://example.com prints just the response headers, where you can read the Set-Cookie session name, an X-Request-Id, and the Server value. Dropping the -I to fetch the full HTML (and searching it for csrf-token) lets you confirm the CSRF marker from the command line without a browser. This is ideal for checking many URLs at once and cross-references neatly with header reading — see how to read a website's HTTP response headers. Pair it with a browser View Source when you want to see the form's authenticity_token in context.

A worked example

Say you are profiling a startup's web app. You open View Source and search for csrf-token — there it is in the head, <meta name="csrf-token" content="...">, paired with a csrf-param meta tag. Scrolling to the login form, you find a hidden authenticity_token field. That combination is a strong Rails signal already. You confirm in DevTools: the Application tab shows a _myapp_session cookie, and the Network tab lists the stylesheet as /assets/application-3f2a9c....css — the fingerprinted asset pattern. curl -I returns an X-Request-Id header and a Server value indicating Puma. Every signal aligns: this is a Ruby on Rails application, served by Puma, using the standard asset pipeline. In a couple of minutes you have the backend framework and a sense of the deployment — a complete read of an otherwise quiet server-side stack.

Distinguishing Rails from other Ruby and full-stack frameworks

Ruby has other frameworks, and several frameworks in other languages share surface conventions, so it helps to separate them. Sinatra and Hanami are lighter Ruby frameworks that do not ship Rails' authenticity_token/csrf-token convention or its asset-pipeline fingerprinting, so a Ruby site lacking those markers may be one of them rather than Rails. Outside Ruby, remember that Django and Laravel also use CSRF tokens, but with different mechanics — Django via a csrftoken cookie and a csrfmiddlewaretoken form field, Laravel via an XSRF-TOKEN cookie and laravel_session — so the specific token names and the meta-tag pattern matter. Rails' tell is the csrf-token meta tag plus an authenticity_token field and a _session-suffixed cookie; Django's is a csrftoken cookie with /admin/ and /static/; Laravel's is XSRF-TOKEN plus laravel_session. Reading the exact names, not just "there's a CSRF token", is what pins down Rails. For the neighbours, see how to tell if a website is built with Django and how to tell if a website is built with Laravel.

What knowing it's Rails tells you

The framework is an informative single fact. Rails signals a Ruby application built by a team using a mature, convention-driven framework with strong defaults — which says something about engineering style and the talent involved. It implies an Active Record/relational data layer, server-rendered views (often enhanced with Hotwire/Turbo for SPA-like interactivity without a heavy JavaScript framework), and Rails' batteries-included tooling. For competitive research it reveals how a rival builds; for sales qualification it identifies the stack and the integrations a prospect can support; for hiring and partnerships it signals the skills required. Rails is common among startups and product companies with a pragmatic, fast-shipping culture, so spotting it carries useful context. This is exactly the kind of signal that feeds technographic qualification.

How reliable is Rails detection?

Reliable when the signals are present — and Rails is somewhat easier than its server-side peers because its CSRF protection forces markers into the client-visible HTML. The csrf-token meta tag plus an authenticity_token field is a strong, near-definitive combination, and a _session-suffixed cookie with fingerprinted /assets/ files makes it confident. The limits are configuration and infrastructure: a team can rename the session cookie, strip the X-Request-Id header, customise error pages, and front the app with a CDN or reverse proxy that masks signals — though the CSRF markers are hard to remove without breaking form security. So presence is strong evidence, absence is weak evidence — not seeing one signal does not mean the site is not Rails, only that that particular tell is not exposed where you looked. Combine the CSRF markers, the cookie, the assets and the headers, and where two or more agree you can state "this is Rails" with genuine confidence; where they conflict or are absent, report the uncertainty rather than guessing.

The workflow

1. View Source and search for csrf-token (head) and authenticity_token (forms).
2. Check the Application tab for a session cookie ending in _session.
3. Scan asset links for the /assets/application-<hash>.css/js fingerprint pattern.
4. Run curl -I to read X-Request-Id and the Server value (often Puma).
5. Combine the signals — the CSRF markers plus a cookie or fingerprinted assets means Rails with confidence.

Go deeper

• The whole stack: how to find out what technology a website uses.
• The language underneath: how to find out what programming language a website uses.
• The headers that corroborate it: how to read a website's HTTP response headers.
• A server-side neighbour: how to tell if a website is built with Django.

Want the backend framework, language and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.