S3 Presigned URL File Size Limit: Upload Caps, Multipart Transfers & Alternatives

An Amazon S3 presigned URL upload will fail abruptly if client software attempts to send more than 5 GB in a single HTTP request. The Amazon S3 presigned URL file size limit is strictly 5 GB for a single HTTP PUT operation, governed by the underlying PutObject API ceiling as documented in the AWS Documentation. According to official AWS documentation, with a single PUT operation, you can upload a single object up to 5 GB in size. Attempting to transmit a payload exceeding 5,368,709,120 bytes via a standard presigned PUT URL causes Amazon S3 to reject the connection immediately with an EntityTooLarge error.

The S3 presigned URL file size limit is strictly 5 GB for a single HTTP PUT operation; uploading objects larger than 5 GB up to the 5 TB S3 maximum requires orchestrating multipart uploads with individually presigned part URLs.

Most developer tutorials explain that Amazon S3 accommodates objects up to 5 TB, leading engineers to assume that a standard presigned PUT URL accepts files of any size. In production environments, this assumption leads to severe pipeline disruptions. When an application hands off a large disk image, video archive, or dataset to an Amazon S3 presigned URL for a single PUT upload, the transfer halts the moment the byte stream reaches the 5 GB boundary. The client receives an HTTP 400 Bad Request error stating that the proposed upload exceeds the maximum allowed object size, forcing engineering teams to write client-side chunking and assembly routines.

Key Architectural Thresholds for S3 Presigned Uploads

Understanding how Amazon S3 processes direct-to-bucket uploads requires differentiating between single-request operations and multi-part transfers. Amazon S3 provides two primary mechanisms for direct uploads without sharing IAM credentials: presigned PUT URLs and presigned POST policies. Both mechanisms share the same 5 GB single-operation threshold, but they manage constraints differently:

• Single Presigned PUT URL: Amazon S3 restricts a single PUT request to an object size of 5 GB (5,368,709,120 bytes). The client streams the entire file directly to the S3 bucket using a standard HTTP PUT request. Uploading objects in a single operation requires no preliminary multipart handshake, but the request cannot pause, resume, or exceed the 5 GB ceiling.
• Presigned POST (HTML Form Upload): Amazon S3 limits a single POST upload operation to an object size of 5 GB. Unlike PUT, presigned POST operations allow backend services to enforce strict minimum and maximum byte boundaries before transmission starts using the policy condition content-length-range.
• Presigned Multipart Upload: Extends upload capacity up to the 5 TB Amazon S3 object ceiling. The backend initiates a multipart session, generates up to 10,000 individually presigned part URLs, and the client uploads discrete chunks ranging from 5 MB to 5 GB each before calling the completion endpoint.

Presigned Upload Ceilings Across Methods and Cloud Environments

Network proxies, browser sandboxes, and modern AI agent runtimes impose additional constraints on large file transfers. In Claude chat sessions, users can upload up to 20 files at up to 500MB each, while Claude Projects accept files up to 30MB each, with file volume ultimately bounded by context window capacity, as documented in the Anthropic Help Center.

The following comparison details standard default limits, maximum configurable thresholds, and primary failure mechanisms across S3 upload patterns and cloud workspace infrastructure:

When architects design file intake pipelines for applications or automated AI agents, selecting the correct transfer pattern avoids unexplained HTTP 400 errors and unexpected transfer aborts.

• SFTP File Size Limit: Protocol Constraints, Packet Buffers, and Large TransfersThe SSH File Transfer Protocol (SFTP) imposes no fixed protocol-level file size ceiling, using 64-bit integer offsets...
• Notion File Upload Limits: Size Caps by Plan and Large-File WorkaroundsNotion limits individual file uploads to 5MB on the Free plan and provides unlimited file uploads with a 5GB maximum...
• AWS Lambda File Size Limits: Payload, Package, and Ephemeral Storage CapsAn AWS Lambda file size limit encompasses the execution constraints of AWS Lambda functions, specifically the 50MB...
• Cloudflare Upload Limits: Plan Caps, Error 413, and WorkaroundsCloudflare restricts client request bodies passing through its edge proxy to 100 MB on Free and Pro tiers, 200 MB on...
• Box File Size Limit: Upload Caps by Plan and Large-Corpus AI SearchBox documents an individual file upload limit across account plans, ranging from 250 MB on free accounts to 5 GB on...
• OneDrive File Size Limit: Upload Caps, Sync Bottlenecks, and AI Large-Corpus WorkspacesThe OneDrive file size limit is 250 GB per individual file across all account types, including Personal, Business, and...

More on this subject: Agent File and Document Workflows (298 guides)

The 5 GB single-object transfer ceiling on an Amazon S3 presigned URL upload is an immutable service constraint rather than a configurable bucket setting. It is an architectural protocol boundary enforced by the Amazon S3 PutObject API.

The PutObject Protocol Boundary and EntityTooLarge Errors

The standard presigned PUT URL delegates the HTTP PUT method directly to the Amazon S3 REST API endpoint. In the HTTP specification, a PUT operation is an atomic transfer of a single resource representation across an established TCP socket.

When a client transmits data to a presigned PUT URL, Amazon S3 inspects the incoming byte stream. If the client sends a Content-Length header exceeding 5,368,709,120 bytes, or if the streaming payload passes that byte mark without closing the stream, the Amazon S3 storage frontend immediately halts the upload. The connection terminates, and S3 returns an HTTP 400 Bad Request error containing the following XML payload:

<Error>
  <Code>EntityTooLarge</Code>
  <Message>Your proposed upload exceeds the maximum allowed size</Message>
  <ProposedSize>5368709121</ProposedSize>
  <MaxSizeAllowed>5368709120</MaxSizeAllowed>
  <RequestId>3EXAMPLE12345678</RequestId>
  <HostId>examplehostid1234567890abcdefghijklmnopqrstuvwxyz=</HostId>
</Error>

This failure happens because single-operation PUT uploads lack internal checkpointing. If an application attempts to transmit a high-capacity file over a single HTTP PUT connection and experiences a momentary packet loss or socket timeout near the end, the entire request fails. The HTTP protocol provides no standard mechanism to resume an interrupted atomic PUT request from an arbitrary byte offset. Allowing multi-gigabyte or terabyte files to upload through single PUT streams would cause widespread socket exhaustion, buffer bloating, and high retransmission waste across global networks.

S3 Presigned POST Constraints and Policy Conditions

A common alternative to the presigned PUT URL is the presigned POST request. While presigned PUT uses a standard HTTP URL with query parameter signatures, presigned POST uses an HTML form upload with multipart/form-data encoding and an IAM-signed base64 policy document.

The S3 presigned POST file size limit is 5 GB for a single upload operation. However, presigned POST offers a critical advantage over presigned PUT: proactive client-side size enforcement. In a standard presigned PUT request, the server cannot restrict the client to a specific size window unless the backend signs the Content-Length header, which requires knowing the exact file size down to the byte in advance.

With presigned POST, backend services define an explicit size range in the policy document using the content-length-range condition. If a user or automated script attempts to transmit a file that falls outside this range, Amazon S3 terminates the upload immediately.

Here is an example of generating an Amazon S3 presigned POST policy with explicit file size boundaries in Python using boto3:

import boto3

s3_client = boto3.client('s3')

min_bytes = 1024  # minimum 1 KB
max_bytes = 500 * 1024 * 1024  # maximum 500 MB

presigned_post = s3_client.generate_presigned_post(
    Bucket='application-intake-bucket',
    Key='uploads/${filename}',
    Fields={'acl': 'private'},
    Conditions=[
        {'acl': 'private'},
        ['content-length-range', min_bytes, max_bytes],
        ['starts-with', '$key', 'uploads/']
    ],
    ExpiresIn=3600
)

The conditions array instructs Amazon S3 to reject any upload where the body length is less than 1,024 bytes or greater than 524,288,000 bytes. If an incoming file exceeds max_bytes, Amazon S3 returns an EntityTooLarge response before the client exhausts network bandwidth.

Even with presigned POST, Amazon S3 restricts the maximum single upload object size to 5 GB (5,368,709,120 bytes). Setting a higher value will result in policy rejection when the client uploads the payload. For files exceeding 5 GB, engineering teams must transition to multipart uploads.

When application workflows require uploading files that exceed 5 GB, the single PUT pattern must be replaced by a presigned multipart upload workflow. According to official AWS documentation, multipart upload allows you to upload a single object as a set of parts. Each part is a contiguous portion of the object's data, allowing files up to 5 TB to be uploaded reliably into Amazon S3 across independent chunks.

A presigned multipart upload decouples file transfer into independent chunks. Each chunk is uploaded to its own presigned URL, and Amazon S3 stitches the parts together into a single finished object upon completion.

The Four Stages of Presigned Multipart Uploads

Implementing presigned multipart uploads requires coordination between the client application and a backend service with AWS credentials:

1. Upload Initialization: The client contacts the backend API with the file name and content type. The backend calls the Amazon S3 CreateMultipartUpload API, which creates an active upload session in the target bucket and returns an UploadId.
2. Part URL Generation: The client calculates the total number of parts required based on a chosen chunk size (between 5 MB and 5 GB) for the Amazon S3 multipart upload. The backend generates an individually presigned PUT URL for each part number using the UploadPart operation and the UploadId.
3. Chunk Transmission and ETag Collection: The client slices the file locally and uploads each chunk to its corresponding presigned part URL. For every successful part upload, Amazon S3 returns an HTTP 200 OK response with an ETag header containing the MD5 checksum of that specific chunk. The client records each part number and its corresponding ETag.
4. Assembly and Completion: After all parts have finished uploading, the client sends the complete list of part numbers and ETags back to the backend service. The backend calls CompleteMultipartUpload, instructing Amazon S3 to assemble the chunks into the final object.

Backend Orchestration Example in Node.js

The following backend service implementation demonstrates how to initialize an upload, generate presigned URLs for each chunk, and complete the multipart upload using the AWS SDK for JavaScript v3:

import {
  S3Client,
  CreateMultipartUploadCommand,
  UploadPartCommand,
  CompleteMultipartUploadCommand,
  AbortMultipartUploadCommand
} from '@aws-sdk/client-s3';
import { getSignedUrl } from '@aws-sdk/s3-request-presigner';

const s3 = new S3Client({ region: 'us-east-1' });

// 1. Initialize the multipart session and retrieve an UploadId
export async function initializeMultipartUpload(bucket, key, contentType) {
  const command = new CreateMultipartUploadCommand({
    Bucket: bucket,
    Key: key,
    ContentType: contentType
  });
  const response = await s3.send(command);
  return response.UploadId;
}

// 2. Generate presigned URLs for each discrete part
export async function generatePartUrls(bucket, key, uploadId, totalParts) {
  const presignedUrls = [];
  for (let partNumber = 1; partNumber <= totalParts; partNumber++) {
    const command = new UploadPartCommand({
      Bucket: bucket,
      Key: key,
      UploadId: uploadId,
      PartNumber: partNumber
    });
    const url = await getSignedUrl(s3, command, { expiresIn: 3600 });
    presignedUrls.push({ partNumber, url });
  }
  return presignedUrls;
}

// 3. Finalize the upload by submitting the completed part list
export async function completeMultipartUpload(bucket, key, uploadId, parts) {
  const sortedParts = parts.sort((a, b) => a.PartNumber - b.PartNumber);
  const command = new CompleteMultipartUploadCommand({
    Bucket: bucket,
    Key: key,
    UploadId: uploadId,
    MultipartUpload: {
      Parts: sortedParts
    }
  });
  return await s3.send(command);
}

// 4. Clean up stalled sessions if an unrecoverable failure occurs
export async function abortMultipartUpload(bucket, key, uploadId) {
  const command = new AbortMultipartUploadCommand({
    Bucket: bucket,
    Key: key,
    UploadId: uploadId
  });
  return await s3.send(command);
}

Calculating Part Sizes and the 10,000 Part Limit

Amazon S3 enforces strict rules on part sizes and counts within multipart uploads:

• Part Size Minimum: In Amazon S3 multipart uploads, every part except the final chunk must be at least 5 MB (5,242,880 bytes). If an intermediate part is smaller than 5 MB in an Amazon S3 multipart upload, the service rejects the request with an EntityTooSmall error.
• Part Size Maximum: For Amazon S3 multipart uploads, an individual part cannot exceed 5 GB (5,368,709,120 bytes).
• Maximum Part Count: An upload can have at most 10,000 parts, numbered sequentially from 1 to 10,000.

Because the maximum part count is fixed at 10,000, your chunk size directly determines the maximum file size you can upload. The maximum file size equals the part size multiplied by 10,000.

If your client application uses the minimum 5 MB chunk size for Amazon S3 multipart uploads, the maximum file it can upload across 10,000 parts is 50 GB. Attempting an Amazon S3 multipart upload with 5 MB chunks across a 200 GB archive will breach the 10,000-part boundary, causing S3 to reject part number 10,001.

To calculate the appropriate part size for any given file size in client code:

function calculatePartSize(fileSizeBytes) {
  const MIN_PART_SIZE = 5 * 1024 * 1024; // 5 MB
  const MAX_PARTS = 10000;
  
  // Ensure the chunk size allows the file to fit within 10,000 parts
  const calculatedSize = Math.ceil(fileSizeBytes / MAX_PARTS);
  
  const DEFAULT_PREFERRED_SIZE = 50 * 1024 * 1024; // 50 MB
  return Math.max(MIN_PART_SIZE, Math.max(DEFAULT_PREFERRED_SIZE, calculatedSize));
}

For Amazon S3 multipart uploads, configuring a part size of 50 MB to 100 MB offers an effective balance between network retry granularity and request overhead.

Scale Beyond S3 Upload Bottlenecks in Agent Workspaces

Bypass single-request timeouts and manual multipart chunking scripts with Fast.io shared workspaces. Connect AI agents via the Model Context Protocol at mcp.fast.io, upload files up to 100 GB on Enterprise plans, and query corpora with built-in semantic search. Monthly plans start with a 14-day free trial that requires a credit card.

Start 14-Day Trial

While backend services handle credential delegation and URL generation, client applications carry the responsibility of chunking file data, transmitting HTTP requests, and handling transient network failures.

Slicing Blobs and Managing Concurrency

In browser applications and Node.js worker scripts, large files should be sliced into discrete binary segments using standard Blob or Buffer slicing methods.

When transmitting parts from a browser, client code must read the ETag header returned by Amazon S3. For this to work, your Amazon S3 bucket CORS configuration must explicitly expose the ETag header. If ExposeHeaders does not include ETag, browser security restrictions prevent JavaScript from reading the response header, causing the completion call to fail.

Here is a standard S3 CORS configuration allowing browser-based multipart uploads:

[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["PUT", "POST", "GET"],
    "AllowedOrigins": ["https://yourdomain.com"],
    "ExposeHeaders": ["ETag"]
  }
]

To optimize upload speeds without overloading client memory or saturating network bandwidth, upload parts using a bounded concurrency queue. Transmitting 3 to 5 parts in parallel maximizes throughput across broadband connections while preventing connection timeouts.

Pausing and Resuming Presigned Uploads

A frequent question among cloud developers is whether an S3 presigned URL upload can be paused and resumed.

A single presigned PUT URL cannot be paused or resumed. If an upload connection breaks mid-stream on a single PUT transfer, the client cannot issue an HTTP Range header to resume the PUT request. The client must retransmit the entire payload from byte zero.

Multipart presigned uploads provide built-in resumability at the part boundary. When a client pauses an upload or loses network connectivity, all chunks that received an HTTP 200 OK response with an ETag remain stored in Amazon S3 staging. To resume the transfer:

1. The client retrieves the active UploadId and the list of already completed part numbers from local persistence (such as IndexedDB or a local cache file).
2. The client checks missing part numbers against the file length.
3. The client requests presigned URLs only for the remaining unuploaded parts.
4. Once missing chunks complete, the client submits the consolidated ETag list to CompleteMultipartUpload.

This architectural difference makes multipart uploads essential for any file transfer exceeding several hundred megabytes over cellular, satellite, or public Wi-Fi networks.

Preventing Orphaned Storage Costs with Lifecycle Rules

When multipart uploads fail midway, or when users close their browser before completion, the parts already transmitted do not disappear. They remain stored in your S3 bucket as hidden incomplete multipart parts.

Because these incomplete parts do not appear as visible objects when browsing the bucket, teams often overlook them. However, AWS continues to bill standard monthly storage charges for every gigabyte of incomplete parts. Over several months, aborted multi-gigabyte uploads can accumulate substantial unmonitored storage costs.

To prevent orphaned part accumulation, configure an Amazon S3 Lifecycle Rule on your intake bucket that automatically aborts incomplete multipart uploads:

{
  "Rules": [
    {
      "ID": "PurgeIncompleteMultipartUploads",
      "Status": "Enabled",
      "Filter": {},
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    }
  ]
}

This lifecycle rule instructs Amazon S3 to delete all partial data associated with any multipart upload that has not completed within 7 days of initiation, reclaiming storage capacity automatically.

As organizations deploy autonomous AI agents (such as Claude Code, Cursor, Codex, and OpenClaw) into production workflows, managing file intake boundaries becomes a central architectural problem.

Autonomous coding and analysis agents routinely process high-capacity file corpora: database dumps, video assets, compiled binary distributions, and historical document archives. However, transmitting massive files directly through AI models quickly hits hard context window boundaries. In Claude chat sessions, users can upload up to 20 files at up to 500MB each, while Claude Projects accept files up to 30MB each, with file volume ultimately bounded by context window capacity, as documented in the Anthropic Help Center. Passing raw binary files or large corpora directly into model prompts exhausts context space and drives up inference costs.

Orchestrating direct S3 presigned multipart uploads inside autonomous agents introduces significant friction:

• Complex Client Code: Agents must execute multipart initialization, handle dynamic part slicing, maintain ETag arrays, manage concurrency pools, and call completion endpoints.
• Passive, Unindexed Storage: Amazon S3 is a passive object store. Uploaded objects remain unparsed bytes. If an agent needs to extract answers from an archive of legal filings or technical manuals, it cannot query the bucket semantically without provisioning separate vector databases and indexing pipelines.
• Concurrency Overwrites: S3 PUT operations lack native advisory locking. Two agents generating outputs to the same S3 key will overwrite each other without warning, unless complex versioning and conditional writes are scripted.

Upgrading to Fast.io Intelligent Workspaces

Fast.io provides a collaborative cloud platform purpose-built for agentic teams through shared workspaces. Instead of requiring engineering teams to maintain custom S3 multipart orchestration scripts, bucket lifecycle rules, and external vector indexing layers, Fast.io handles large file transfers natively within an intelligent storage environment.

• High-Capacity File Ingestion: Fast.io supports large single-file transfers natively without requiring client chunking scripts, scaling direct upload ceilings across subscription tiers as detailed in the plan breakdown below.
• Built-in Intelligence Mode: When Intelligence is enabled on a workspace, incoming files are automatically indexed on arrival. Fast.io provides hybrid Search combining full-text indexing, semantic search, and search-by-metadata-value. Autonomous agents query document contents and extract answers with citations directly through chat or MCP, avoiding the need to ingest entire multi-gigabyte archives into prompt context.
• Structured Data Extraction with Metadata Views: With Metadata Views, workspaces transform unorganized documents into live, queryable spreadsheets without writing custom OCR code or regex parsers.
• Advisory File Locks: Concurrent multi-agent access is protected by advisory per-file leases in workspace storage. Leases are acquired and released through MCP actions: lock-acquire and lock-release on the storage_manage tool, and lock-status on the storage tool. Locks expire automatically unless heartbeated, so stalled agents never deadlock a pipeline. Concurrent writes both land safely, and per-file version history preserves every version.
• Detailed Activity Log: Workspaces maintain a detailed activity log tracking what changed in an organization and who changed it, including uploads, edits, moves, deletions, membership changes, and share creation (without logging passive file views or downloads).
• Cloud Sync and Import: Workspaces can import files directly from Google Drive, Dropbox, Box, and OneDrive via URL without consuming local bandwidth. Cloud Sync is available for Google Drive, Dropbox, Box, and OneDrive (one-way or two-way, on a schedule or on demand, never continuous or real-time).

Connecting AI Agents via Fast.io Model Context Protocol (MCP)

Developers connect autonomous agents directly to Fast.io workspaces using the Model Context Protocol (MCP) over Streamable HTTP. Instead of maintaining custom AWS IAM roles and presigned URL generators, agents authenticate via OAuth or scoped Bearer API keys using designated endpoints:

• https://mcp.fast.io/mcp/tools for Claude desktop, mobile, web, Claude Cowork, and general personal-agent clients.
• https://mcp.fast.io/mcp/code for coding agents operating in IDEs and terminals, including Claude Code, Cursor, Cline, and Gemini CLI.
• https://mcp.fast.io/mcp/operations for custom ChatGPT and Codex configurations (with the Fastio plugin being the preferred setup in ChatGPT and Codex).

Refer to the Fast.io MCP documentation for client-specific configuration steps.

The following table summarizes available plans and storage tiers for teams and agentic workflows:

Monthly plans start with a 14-day free trial that requires a credit card. Teams can explore available plan options on the pricing page or review developer guides under storage for agents.