Websites generally need to serve additional files such as images, JavaScript,or CSS. In Django, we refer to these files as “static files”. Django providesdjango.contrib.staticfiles to help you manage them.

This page describes how you can serve these static files.

Make sure that django.contrib.staticfiles is included in yourINSTALLED_APPS.

In your settings file, define STATIC_URL, for example:

In your templates, use the static template tag to build the URL forthe given relative path using the configured staticfilesSTORAGES alias.

Store your static files in a folder called static in your app. Forexample my_app/static/my_app/example.jpg.

Serving the files

In addition to these configuration steps, you’ll also need to actuallyserve the static files.

During development, if you use django.contrib.staticfiles, this willbe done automatically by runserver when DEBUG is setto True (see django.contrib.staticfiles.views.serve()).

This method is grossly inefficient and probably insecure,so it is unsuitable for production.

See How to deploy static files for proper strategies to servestatic files in production environments.

Your project will probably also have static assets that aren’t tied to aparticular app. In addition to using a static/ directory inside your apps,you can define a list of directories (STATICFILES_DIRS) in yoursettings file where Django will also look for static files. For example:

See the documentation for the STATICFILES_FINDERS setting fordetails on how staticfiles finds your files.

Static file namespacing

Now we might be able to get away with putting our static files directlyin my_app/static/ (rather than creating another my_appsubdirectory), but it would actually be a bad idea. Django will use thefirst static file it finds whose name matches, and if you had a static filewith the same name in a different application, Django would be unable todistinguish between them. We need to be able to point Django at the rightone, and the best way to ensure this is by namespacing them. That is,by putting those static files inside another directory named for theapplication itself.

You can namespace static assets in STATICFILES_DIRS byspecifying prefixes.

If you use django.contrib.staticfiles as explained above,runserver will do this automatically when DEBUG is setto True. If you don’t have django.contrib.staticfiles inINSTALLED_APPS, you can still manually serve static files using thedjango.views.static.serve() view.

This is not suitable for production use! For some common deploymentstrategies, see How to deploy static files.

For example, if your STATIC_URL is defined as static/, you cando this by adding the following snippet to your urls.py:

Note

This helper function works only in debug mode and only ifthe given prefix is local (e.g. static/) and not a URL (e.g.http://static.example.com/).

Also this helper function only serves the actual STATIC_ROOTfolder; it doesn’t perform static files discovery likedjango.contrib.staticfiles.

Finally, static files are served via a wrapper at the WSGI applicationlayer. As a consequence, static files requests do not pass through thenormal middleware chain.

During development, you can serve user-uploaded media files fromMEDIA_ROOT using the django.views.static.serve() view.

This is not suitable for production use! For some common deploymentstrategies, see How to deploy static files.

For example, if your MEDIA_URL is defined as media/, you can dothis by adding the following snippet to your ROOT_URLCONF:

Note

This helper function works only in debug mode and only ifthe given prefix is local (e.g. media/) and not a URL (e.g.http://media.example.com/).

When running tests that use actual HTTP requests instead of the built-intesting client (i.e. when using the built-in LiveServerTestCase) the static assets need to be served alongthe rest of the content so the test environment reproduces the real one asfaithfully as possible, but LiveServerTestCase has only very basic staticfile-serving functionality: It doesn’t know about the finders feature of thestaticfiles application and assumes the static content has already beencollected under STATIC_ROOT.

Because of this, staticfiles ships its owndjango.contrib.staticfiles.testing.StaticLiveServerTestCase, a subclassof the built-in one that has the ability to transparently serve all the assetsduring execution of these tests in a way very similar to what we get atdevelopment time with DEBUG = True, i.e. without having to collect themusing collectstatic first.

django.contrib.staticfiles provides a convenience management commandfor gathering static files in a single directory so you can serve them easily.

Set the STATIC_ROOT setting to the directory from which you’dlike to serve these files, for example:

Run the collectstatic management command:

This will copy all files from your static folders into theSTATIC_ROOT directory.

Use a web server of your choice to serve thefiles. How to deploy static files covers some common deploymentstrategies for static files.

This document has covered the basics and some common usage patterns. Forcomplete details on all the settings, commands, template tags, and other piecesincluded in django.contrib.staticfiles, see the staticfilesreference.