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: February 12, 2026|Editorial standard: source-backed technical guidance
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).
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.
Decision Support
Compare Guide
HTTP 400 vs 422: Bad Request vs Unprocessable Content
Fix API payload issues faster by using 400 for malformed syntax and 422 for semantic validation failures, so clients correct format before business rules.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Playbook
Validation Failure Playbook (400 / 422 / INVALID_ARGUMENT)
Use this playbook to separate malformed-request failures from semantic validation failures, then fix request contracts without broad server-side bypasses.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.