December 3, 2025
Welcome to Django 6.0!
These release notes cover the new features, as well as some backwards incompatible changes you should be aware of when upgrading from Django 5.2 or earlier. We’ve begun the deprecation process for some features.
See the How to upgrade Django to a newer version guide if you’re updating an existing project.
The Django 5.2.x series is the last to support Python 3.10 and 3.11.
Django 6.0 supports Python 3.12, 3.13, and 3.14. We highly recommend , and only officially support, the latest release of each series.
Following the release of Django 6.0, we suggest that third-party app authors drop support for all versions of Django prior to 5.2. At that time, you should be able to run your package’s tests using python -Wd so that deprecation warnings appear. After making the deprecation warning fixes, your app should be compatible with Django 6.0.
What’s new in Django 6.0¶
Content Security Policy support¶ Built-in support for the Content Security Policy (CSP) standard is now available, making it easier to protect web applications against content injection attacks such as cross-site scripting (XSS). CSP allows declaring trusted sources of content by giving browsers strict rules about which scripts, styles, images, or other resources can be loaded. CSP policies can now be enforced or monitored directly using built-in tools: headers are added via the ContentSecurityPolicyMiddleware , nonces are supported through the csp() context processor, and policies are configured using the SECURE_CSP and SECURE_CSP_REPORT_ONLY settings. These settings accept Python dictionaries and support Django-provided constants for clarity and safety. For example: from django.utils.csp import CSP SECURE_CSP = { "default-src" : [ CSP . SELF ], "script-src" : [ CSP . SELF , CSP . NONCE ], "img-src" : [ CSP . SELF , "https:" ], } The resulting Content-Security-Policy header would be set to: default-src 'self'; script-src 'self' 'nonce-SECRET'; img-src 'self' https: To get started, follow the CSP how-to guide. For in-depth guidance, see the CSP security overview and the reference docs, which include details about decorators to override or disable policies on a per-view basis.
Background Tasks¶ Django now includes a built-in Tasks framework for running code outside the HTTP request–response cycle. This enables offloading work, such as sending emails or processing data, to background workers. The framework provides task definition, validation, queuing, and result handling. Django guarantees consistent behavior for creating and managing tasks, while the responsibility for running them continues to belong to external worker processes. Tasks are defined using the task() decorator: from django.core.mail import send_mail from django.tasks import task @task def email_users ( emails , subject , message ): return send_mail ( subject , message , None , emails ) Once defined, tasks can be enqueued through a configured backend: email_users . enqueue ( emails = [ "[email protected]" ], subject = "You have a message" , message = "Hello there!" , ) Backends are configured via the TASKS setting. The two built-in backends included in this release are primarily intended for development and testing. Django handles task creation and queuing, but does not provide a worker mechanism to run tasks. Execution must be managed by external infrastructure, such as a separate process or service. See Django’s Tasks framework for an overview and the Tasks reference for API details.