EntityTooSmall
AWS EntityTooSmall (Entity Too Small) means a multipart upload part is below the minimum allowed size (except the final part). In Amazon S3, this error returns HTTP 400.
Last reviewed: March 18, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Entity Too Small Mean?
S3 rejects multipart upload progress at part validation time, so large-file ingestion stalls until chunk sizing and final-part detection are corrected.
Common Causes
- -A non-final multipart upload part is sent below the minimum part size.
- -Client chunking logic splits payload into overly small parts.
- -Upload final-part detection is incorrect, so a midstream part is treated as non-final and too small.
- -Small objects are sent through multipart upload when single-request PutObject would be appropriate.
How to Fix Entity Too Small
- 1Set multipart part size to at least 5 MB for all non-final parts.
- 2Use PutObject for small files instead of multipart upload.
- 3Re-run upload with a fixed chunker and restart the multipart session if parts are already invalid.
- 4Validate part numbering and final-part detection in the uploader implementation.
Step-by-Step Diagnosis for Entity Too Small
- 1Confirm whether the failing flow uses multipart upload (UploadPart/CompleteMultipartUpload).
- 2Log every part number and byte size; identify any non-final part below minimum size.
- 3Verify the last part is the only part allowed to be under the standard part-size threshold.
- 4Inspect uploader chunking logic for boundary errors during stream flush or resume.
Multipart Part-Size Audit
- -Inspect every UploadPart request and verify non-final parts are >= 5 MiB (example: part 7 at 1.2 MiB fails while not being final).
- -Correlate part-number sequence with stream boundaries (example: resume logic marks a middle chunk as complete-final and emits undersized trailing parts).
Uploader Chunker and Resume Logic
- -Audit chunker implementation for flush behavior under low-buffer conditions (example: periodic flush emits sub-5 MiB chunks during network jitter).
- -Verify retry/resume paths preserve original part boundaries (example: resumed transfer restarts with new chunk size and violates multipart minimum).
Seen in Production
Multipart uploader emits undersized intermediate chunks
Frequency: common
Example: A custom uploader sends 1 MB chunks and triggers EntityTooSmall during UploadPart.
Fix: Increase configured part size and ensure only the final part can be below standard multipart size.
Small files are routed through multipart path unnecessarily
Frequency: rare
Example: A pipeline always uses multipart, including tiny files better handled by PutObject.
Fix: Route small files to PutObject and reserve multipart upload for larger objects.
Debugging Tools
- -aws s3api list-parts
- -AWS CLI --debug request traces
- -Uploader chunk-size telemetry
- -Multipart integration tests
How to Verify the Fix
- -Repeat the same upload and confirm EntityTooSmall is no longer returned.
- -Validate part-size telemetry shows all non-final parts at or above minimum threshold.
- -Confirm uploaded object integrity and expected object size after completion.
How to Prevent Recurrence
- -Enforce minimum multipart part size in shared uploader libraries.
- -Add tests for edge cases around stream boundaries, retries, and resume behavior.
- -Track multipart part-size distributions and alert on undersized non-final parts.
Pro Tip
- -lock multipart part size at upload-start metadata and disallow runtime chunk-size changes during retries or resumptions.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.