How to Tell if a Website Is Built with Django

If you want to know whether a website is built with Django, the fastest answer is to check its cookies and asset paths: a default Django application sets a csrftoken cookie (and a sessionid cookie in authenticated areas), and it commonly serves static files from /static/ and uploads from /media/. The clincher is often the admin login page — Django's built-in admin has a distinctive default look and lives at a conventional URL. As with any server-side framework, the catch is that Django runs in Python on the server and returns finished HTML, so it leaves far fewer client-side traces than a JavaScript framework. You read it from its side effects. This guide covers every signal, how to check with 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 Django is one of the most common ways a site turns out to be a Python application.

What Django is, briefly

Django is a popular open-source Python web framework. It is "batteries included": it ships with an ORM, a templating system, form handling, authentication, and — famously — an automatic admin interface generated from your data models. Because it is server-side, the work happens on the host: a request arrives, Django's Python code runs, queries the database, renders a template, and returns HTML. The browser never downloads "Django" the way it downloads a React bundle. That shapes detection entirely — you are not looking for a framework script sent to the client, you are looking for the traces a Python server leaves: the cookies it sets for CSRF and sessions, its conventions for serving static and media files, its admin page, and its debug error screen. Django's defaults are consistent enough that those traces are recognisable.

Why server-side frameworks are harder to detect

This limitation explains the whole method, so it is worth stating plainly. A client-side framework is loud: it ships named JavaScript chunks, often inlines a data blob, and mounts into known DOM containers — all visible in View Source and the Network tab. A server-side framework like Django is quiet: the HTML it returns is just HTML, with no framework-branded asset for the browser to fetch. So rather than reading the framework directly, you read the evidence of how the page was produced: the csrftoken and sessionid cookies, the /static/ and /media/ asset paths, the admin login screen, and the distinctive DEBUG error page when debug mode is mistakenly left on. Each is a meaningful hint; together they build a confident picture. This is the same "read the side effects" approach that makes programming-language detection work for server-side stacks generally.

Signal 1: the cookies (a strong tell)

Django's cookies are among the most reliable signals. By default, Django sets:

• csrftoken — the cross-site request forgery token Django uses to protect form submissions. The framework checks it on POST requests to confirm they are genuine. Its name and behaviour are characteristic of Django.
• sessionid — Django's default session cookie, set when a session is established (most visibly in logged-in or admin areas).

Seeing csrftoken, especially alongside sessionid, is a strong Django indicator. To check, open DevTools (F12), go to the Application tab, expand Cookies, and read the cookie names for the domain. You can also catch them from the terminal: curl -I https://example.com prints the response headers and the Set-Cookie lines reveal the names. The nuance: both cookie names are configurable, so a site could rename them — but the defaults appearing, particularly together, are a clear positive. As with all cookie signals, presence is stronger evidence than absence, because some cookies only appear once a session or a form is involved.

Signal 2: /static/ and /media/ asset paths

Django has firm conventions for serving files, and they show up in the HTML. Static files — CSS, JavaScript, images that are part of the site — are conventionally served from a /static/ path (Django's STATIC_URL default). User-uploaded files are conventionally served from a /media/ path (MEDIA_URL). When you View Source or watch the Network tab, links to /static/... and /media/... are a Django-flavoured hint. They are not unique to Django — other stacks use /static/ too — so weight them as supporting rather than conclusive. But combined with the csrftoken cookie, they reinforce the read considerably. The exact paths can be customised or fronted by a CDN, so treat them as corroboration.

Signal 3: the admin login page

This is the signal that often settles it. Django ships an automatic admin interface, conventionally mounted at /admin/, and its default login screen has a very recognisable look — a clean, distinctively styled "Django administration" login form. Navigating to a site's /admin/ path and seeing that screen is a near-giveaway that the site runs Django. Two honest caveats: security-conscious teams frequently move the admin to a non-default URL or restrict access to it, so a missing /admin/ page does not rule Django out; and you should only view a public login page, never attempt to log in or probe it. When the default admin login is exposed, though, it is one of the clearest single confirmations you can find.

Signal 4: the DEBUG error page

Like Laravel's Ignition page, Django has a distinctive debug screen. When DEBUG mode is accidentally left enabled in production and an error occurs, Django returns its unmistakable yellow error page — a detailed traceback that explicitly names Django, often the version, and shows the request and settings context. If you ever encounter that page, detection is settled outright. You should never try to cause errors to provoke it, but if a broken page surfaces the yellow Django traceback, it is definitive. Treat it as a bonus you occasionally stumble upon rather than a target.

Signal 5: headers and framework hints

Headers can corroborate. Django runs on Python, often served via WSGI/ASGI servers like Gunicorn, uWSGI or Uvicorn behind nginx, so the Server header and any application-server hints point toward a Python backend consistent with Django. Django itself does not advertise its name in a standard response header by default, and X-Powered-By is uncommon for Python stacks, so headers are weaker here than for some other frameworks — but a Python application-server signature plus Django's cookies is a coherent combination. Reading headers well is its own skill; see how to read a website's HTTP response headers for the full technique.

The signal table

Signal	Where to find it	What it means
csrftoken cookie	DevTools Application, Set-Cookie header	Django CSRF cookie — strong
sessionid cookie	DevTools Application (esp. logged-in areas)	Django default session cookie — strong
/static/... asset links	View Source, Network tab	Django static-files convention — supporting
/media/... upload links	View Source, Network tab	Django media convention — supporting
/admin/ login screen	Navigate to /admin/	Django's built-in admin — near-definitive when default
Yellow DEBUG error page	A broken page (if DEBUG on)	Definitive when seen
Python app-server Server header	Response headers	Python backend (consistent with Django)

No single supporting signal is conclusive alone, but the cookies plus the admin look — or cookies plus asset paths — make a confident call.

Method 1: the DevTools Application and Network tabs

The most direct check is in DevTools. Open it (F12), go to the Application tab, and read the Cookies for the site — csrftoken and sessionid are what you want. Then switch to the Network tab, reload, click the main document request, and read the Response Headers for Set-Cookie and the Server value. While in the Network tab, note the asset paths for the /static/ and /media/ hints. This live view shows exactly what the server sets and sends — precisely where a server-side framework reveals itself.

Method 2: curl -I from the terminal

For a fast, scriptable check, use the command line. curl -I https://example.com performs a HEAD request and prints just the response headers, where you can read the Set-Cookie names and the Server value. Because the csrftoken cookie may only appear on certain responses, you may prefer to curl the full page or a page with a form to capture it. This is ideal for checking many URLs at once, and it cross-references neatly with header reading — see how to read a website's HTTP response headers. The terminal will not render the admin page for you, so pair it with a browser visit to /admin/ for that signal.

Method 3: View Source and the /admin/ check

A static source view catches the asset-path signals: open the page, press Ctrl/Cmd + U, and search for /static/ and /media/. Then, in a normal browser tab, navigate to the site's /admin/ path and see whether Django's default admin login appears. These two quick checks — source for paths, a visit for the admin screen — complement the cookie and header checks nicely. The cookies confirm the framework's behaviour, the asset paths match its conventions, and the admin page provides the visual clincher when it is at the default URL.

A worked example

Say you are profiling a content-heavy web app. You open DevTools, go to the Application tab, and under Cookies you see a csrftoken cookie — a strong Django hint. You View Source and find the stylesheet and script links all loading from /static/, with article images under /media/, matching Django's conventions. To confirm, you navigate to /admin/ and Django's distinctive "Django administration" login screen loads — that settles it. You do not attempt to log in; the public login screen is confirmation enough. curl -I shows a Server header indicating Gunicorn behind nginx, consistent with a Python deployment. Every signal aligns: this is a Django application, served by a Python app server, with its admin at the default path. 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 Django from other Python setups

Python has several web frameworks, so it helps to separate Django from its neighbours. Flask and FastAPI are lighter Python frameworks that do not ship an admin interface and do not set csrftoken/sessionid by default — Flask's default session cookie is simply session, and FastAPI apps often expose interactive API docs at /docs (Swagger UI) rather than a Django-style admin. So a Python site with a session cookie and a /docs API explorer is more likely Flask or FastAPI than Django. The discriminating questions are: is there a Django-style /admin/ login? are the cookies csrftoken/sessionid? do assets come from /static/ and /media/? If yes, it is Django; if you see a minimal app with different cookies and an API-doc page, look to the lighter frameworks. Reading the specific conventions, not just "it's Python", is what pins down Django.

What knowing it's Django tells you

The framework is an informative single fact. Django signals a Python application built by a team using a mature, batteries-included, well-supported framework — which says something about technical approach and the talent involved. It implies an ORM-backed relational database, server-rendered templates (or Django REST Framework powering an API for a separate front end), and Django's built-in auth and admin. 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. Django is especially common in data-heavy products, content platforms, and teams with a Python/ML bent, so spotting it carries useful context. This is exactly the kind of signal that feeds technographic qualification.

How reliable is Django detection?

Reliable when the signals are present, but honest about its limits. The csrftoken and sessionid cookies are Django defaults, so seeing them is a strong indicator — and the default /admin/ login screen, when exposed, is close to definitive. The limits are configuration and infrastructure: a team can rename the cookies, relocate or lock down the admin URL, disable DEBUG, and front the app with a CDN or reverse proxy that masks signals, leaving a much quieter footprint. So presence is strong evidence, absence is weak evidence — not finding /admin/ or sessionid does not mean the site is not Django, only that the default tell is not exposed where you looked. Combine the cookies, asset paths, admin page and headers, and where two or more agree you can state "this is Django" with genuine confidence; where they conflict or are absent, report the uncertainty rather than guessing.

The workflow

1. Open the Application tab and read cookies for csrftoken and sessionid.
2. View Source for /static/ and /media/ asset paths.
3. Visit /admin/ and check for Django's default admin login screen (view only).
4. Run curl -I to read the Server header and confirm a Python app server.
5. Combine the signals — cookies plus the admin look or asset paths means Django 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.
• The front-end layer on top: how to check what JavaScript libraries a website uses.

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