---
id: KB-DI-017
url: https://app.codecontract.io/help/documents-and-ai/uploading-many-documents-at-once
idioma: en
categoria: documentos-ia
subcategoria: subir
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-DI-003, KB-PS-006, KB-DI-008]
citadoPor: [KB-DI-014]
---

# Uploading many documents at once

_What to decide before dragging in two hundred files, because undoing it afterwards costs more._

**Responde a:** upload many files at once · import a folder of documents · bulk document upload · how many documents can i upload at once

Sooner or later a big block has to go in: a folder from a finished site, the archive of an incoming client, a history being migrated. It can be done, and the result depends almost entirely on three decisions taken before you start, not during.

## The three decisions

1. **Which file each item goes to** — Dropping two hundred files into a generic place is fast and creates a problem you already know: a drawer.
2. **What gets read and what does not** — Not everything deserves extraction. What will be consulted by content, yes; the rest can stay as archive.
3. **And what to do with duplicates** — In a large block there always are: the same document under two names, or two versions of one.

> [!IMPORTANT]
> The second changes the cost most and is the one nobody decides: **every document that is read is an action**. Uploading a two-thousand-file archive and asking for all of it to be read consumes two thousand times, and of those two thousand perhaps fifty will ever be consulted. Reading what will be used and leaving the rest as archive is the difference between bringing your history over and paying to bring it twice.

## What to check before dragging

| Check | Why beforehand |
| --- | --- |
| That names say something | Afterwards they are already in with IMG_4821 as the title |
| That there are no protected files | They upload, but cannot be read or searched |
| That the block belongs to one matter | Mixing two sites in one batch is what creates the drawer |
| And that someone will review what comes in | A bulk upload with no review is archiving, not management |

> [!WARNING]
> The practical nuance that saves an afternoon: **upload a small sample first**. Twenty files of the same type tell you whether the scan quality works, whether the names make sense and whether extraction picks up what you care about. If something is off, fixing it with twenty takes minutes; discovering it with two thousand already in does not.

## After uploading

**En corto**

- Review a random sample, not the first in the list.
- Check that what you wanted is findable, searching the way you really would.
- And note what was brought over and from where, so you do not bring it again next year.

The last looks obvious and is the most repeated error in long migrations: the same folder gets brought over twice because nobody noted that it already was.

> [!NOTE]
> If the block is very large, split it into batches by matter rather than by size. Ten batches of twenty documents from one site each are manageable; one batch of two hundred from ten different sites is a problem to unpick by hand.

**Is there a per-file limit?**

Yes, and it is usually generous: if a file will not fit, it is almost always scanned at far higher resolution than needed.

**Can I upload whole folders?**

It depends how you do it; what matters is which file they land in, not how many there are.

**What if I put the whole block in the wrong file?**

Move it, do not delete: moving keeps the trail and does not consume again.

## Ejemplos

**A company migrates a finished site's archive and asks for everything to be read.**

- Uploads a sample of twenty before the two thousand
- Decides which types get read and which stay as archive

→ The history comes in tidy and consumption stays on what will actually be consulted.

**Three hundred documents are uploaded and nobody knows which failed.**

- Checks the load's result

→ Only what failed gets retried.

**The load cuts out halfway.**

- Checks what went in before repeating

→ What is already uploaded is not duplicated.

**They all land in the same file undifferentiated.**

- Prepares the mapping before loading

→ Each document reaches its place.

**They are loaded with names that say nothing.**

- Names or classifies before uploading

→ They are locatable afterwards.

**A big load runs without a prior test.**

- Tries a small batch

→ The problem is found with ten rather than three hundred.