Django limits non-file request data to 2.5 MB (DATA_UPLOAD_MAX_MEMORY_SIZE) and 1000 GET or POST parameters (DATA_UPLOAD_MAX_NUMBER_FIELDS) by default. Exceeding either raises SuspiciousOperation. Keep the defaults unless a view truly needs more, and enforce a body size limit at your web server too, because Django only checks when the data is accessed.
The two data limits
From Django's settings reference:
| Setting | Default | What it limits |
|---|---|---|
| DATA_UPLOAD_MAX_MEMORY_SIZE | 2621440 bytes (2.5 MB) | Request body size, excluding file upload data |
| DATA_UPLOAD_MAX_NUMBER_FIELDS | 1000 | Number of GET and POST parameters |
| FILE_UPLOAD_MAX_MEMORY_SIZE | 2621440 bytes (2.5 MB) | Size at which an upload is streamed to the file system |
When a limit is exceeded, Django raises SuspiciousOperation: RequestDataTooBig for size, TooManyFields for count. Setting either to None disables the check.
The docs explain why these exist. The amount of request data correlates with the memory needed to populate the GET and POST dictionaries, and the number of parameters correlates with the processing time. Large requests could be used as a denial of service vector if left unchecked.
A detail that matters: when the check runs
The size check happens when you access request.body or request.POST. Until your code touches them, Django has not looked. The docs also say that because web servers do not usually perform deep request inspection, a similar check at that level is not possible, which is a polite way of saying a limit in Django is not a replacement for limits in your front end.
FILE_UPLOAD_MAX_MEMORY_SIZE is not an upload cap
This one confuses people. FILE_UPLOAD_MAX_MEMORY_SIZE is the size at which an upload gets streamed to the file system instead of being held in memory. It is not a maximum file size. A user can still upload a file larger than 2.5 MB, and it will land in a temporary file. If you need a maximum, check the size in your form validation and cap it at the web server.
When to raise the limits
Raise DATA_UPLOAD_MAX_MEMORY_SIZE only for the views that need it, if you can. The docs recommend tuning the setting for applications that expect unusually large form posts. A global increase affects every endpoint, including unauthenticated ones. Consider an approach where large payloads go through a dedicated upload route with authentication and its own limits.
The same logic applies to field counts. A big formset or a bulk edit screen may legitimately exceed 1000 fields. Raise the number to the smallest value that works, not to None.
Layered limits
| Layer | Control |
|---|---|
| Reverse proxy or load balancer | Maximum body size, request timeouts |
| WSGI or ASGI server | Header and body limits, worker timeouts |
| Django | DATA_UPLOAD limits, form validation |
| Application | Per user quotas and rate limits |
Each layer catches different abuse. The proxy stops oversized bodies before they reach Python. Django catches data that gets through. Rate limiting handles many small requests.
Review checklist
- Search settings for DATA_UPLOAD_MAX_MEMORY_SIZE and DATA_UPLOAD_MAX_NUMBER_FIELDS. A value of None deserves a comment.
- Confirm the proxy has a body size limit that matches your largest legitimate upload.
- Validate uploaded file size in forms, not through FILE_UPLOAD_MAX_MEMORY_SIZE.
- Alert on SuspiciousOperation spikes, since they can signal probing.
Try it yourself
Click through it at your own pace, or open it full screen. Observe how a web scan sends unusual requests to see how an app responds.
Quick check
Does FILE_UPLOAD_MAX_MEMORY_SIZE cap the file size?
No. It decides when an upload moves from memory to a temporary file. Enforce your own maximum in validation and at the proxy.
Is it safe to set DATA_UPLOAD_MAX_MEMORY_SIZE to None?
Django allows it, but the docs warn that unchecked large requests can be a denial of service vector. Only do it if another layer enforces a limit.
Safeguard's DAST scanning and policy gates can help you check limits and keep settings changes reviewed. Try a free scan.
Sources
Last reviewed: 19 October 2026.
