# Storage limits and transfer guarantees

Storage limits apply to the expanded operation, not only the number of rows currently visible in the browser. A selected folder can contain many more entries than the selection count suggests.

| Limit | Maximum |
| --- | --- |
| Selected roots per operation | 100 |
| Expanded entries per operation | 10,000 |
| Transferred bytes per file | 1 GiB |
| Transferred bytes per operation | 10 GiB |
| Browser multipart request body | 128 MiB, including multipart overhead |

App ingestion applies its own limits to imports. A file that can be transferred between providers can still exceed an App's ingestion or extraction limits. Use a smaller, relevant source set when processing documents.

## Verification and fidelity

Copies verify destination bytes using SHA-256. Cross-provider moves remove an ordinary source file only after destination verification and a conditional source-revision check. A changed source can therefore remain after the destination copy succeeds.

Transfers do not copy access lists, sharing settings, comments, or provider version history. Native Google documents export into supported formats and remain at the source after cross-provider export moves. Cloud source folders can remain because their current membership cannot be safely removed atomically.

## Completion and recovery

Jobs preserve progress and receipts. Cancellation stops further work and retains completed results. A job can have partial outcomes, and an ambiguous provider mutation requires inspection rather than blind replay.

For a large folder tree, split the selection into deliberate batches that fit both entry and byte limits. Keep receipts so you can reconcile the batches. Reducing the batch size can help isolate a problematic file, but it should not be used to bypass a source-revision refusal or a folder-deletion safeguard.

See [copy and move](/docs/storage/copy-and-move), [jobs](/docs/storage/jobs-and-recovery), and [App imports](/docs/storage/import-into-apps).