Client-Side vs Server-Side CSV Import: How to Choose
When someone uploads a CSV or Excel file, it either stays on the machine that already holds it, or it travels over a network to a server that does the work there.
This post covers what a server-side import does and what its meter counts, what a client-side import does and what limits it, and how to tell which one a given job needs.
What happens in a server-side import
After upload, the file travels across the network. The vendor's infrastructure receives it, holds it while the job runs, parses and validates it, and returns the result to the page or to your backend.
Moving a large file takes machinery of its own. Amazon calls multipart upload a best practice for objects of 100 MB or larger, so the parts can travel in parallel and a failed part can be sent again without restarting the whole file.
The file sits on the vendor's side while the work happens. Every row costs the vendor processor time, memory and storage. Server-side products meter that cost by the rows in a single import, the size of the file, and the number of imports in a billing period.
Holding the file brings duties with it. The vendor encrypts the data on the way and while it sits there. It chooses the region the data lives in, the employees who can open it, the number of days it stays, and the process that deletes it. It writes all of that down, has it audited, and puts it in the contract your procurement team signs. Pay attention to how long your users' data stays there and how much you pay for it.
What a server does well
A machine in a data centre parses a file faster than a laptop does.
The larger advantage is that a server runs unattended. Products built for this pull files from SFTP, S3, cloud drives and shared spreadsheets on hourly, daily or custom cron schedules, run transformations and validation, retry transient failures on their own, and deliver rows to a destination. An API call can start a run, and a webhook reports back when it finishes.
Those jobs need a machine that is always on. The work has to begin on its own, keep going after a failure, and leave a record of what happened.
What happens in a client-side import
After upload, the file is still on the machine that opened the page, and the browser can read it there. Nothing travels before the work starts. Updog Importer reads the file where it sits, the editing happens in the browser, and your code receives clean rows.
That reading does not have to happen on the thread that draws the interface. MDN describes Web Workers as background threads that let code run processor-intensive calculations without blocking the user interface thread. Updog Importer runs parsing, validation, filtering and export in those workers. The grid draws on a canvas, so the browser keeps track of one element instead of a million, and a frame costs whatever the visible part of the screen costs, however many rows sit behind it.
We wrote up how we made Updog Importer fast in the canvas engine and the filter pipeline.
What a browser does well
The row data stays on the machine that opened the page. It is read there, edited there, and handed to your code from there. As of August 2026 Updog Importer makes a single call to us to check the license, and loading a file, editing, validating and exporting send nothing. We wrote up what vendors receive, and what to check before adding one, in data compliance for SaaS.
For the team adding the importer, that removes a step. A vendor that holds customer files gets reviewed as one, and the review asks where the data sits, who can open it, how long it stays and what deletes it. Those questions have no subject when no file arrives.
It also changes what a person can put through the importer. A file with salaries or customer records in it takes the same path as any other file, since it travels from their disk to your code and nowhere else.
What limits a client-side import
Memory and processing speed set the limit. The memory is whatever the browser tab can hold. The speed is whatever a single core can get through, because parsing, sorting, filtering and validating all touch every row, and each of those runs in a worker on one thread. Small files finish fast, and large ones slow down as the row count climbs.
We built Updog Importer to take everything the browser and the machine will give. The limit that remains is theirs, and it is the same on every plan.
However, a million rows is a practical ceiling. On narrower files, fewer columns and no column filters, we have watched five million rows run fast. That is closer to curiosity than to a working number, and a million is the one we will stand behind for the files people import.
When an importer slows down in the tens of thousands of rows, the cost is in how it draws them. A DOM element carries layout and paint cost that a canvas pixel does not, so an importer built on an HTML table meets that ceiling wherever the parsing happens. The rows behind the table can still fit in memory and still be cheap to scan.
Which mode your job needs
Client-side and server-side are modes, and one product can sell both, so the choice belongs to the job. The numbers and modes, product by product, are in the roundup of CSV importers.
File size. How many rows do your files carry, and how many columns? A browser handles up to about a million rows. Past that the work moves to a server.
Who starts the import. Does a person click Import, or does a system deliver a file on a schedule? A person in the loop works in both models, since a server-side importer shows a UI and does the processing behind it. Running with nobody there is the part only a server can do.
Metered imports. Are you willing to pay by rows, file size and import count as your volume grows? That is how server-side products bill, and the bill follows your users' activity.
If none of those answers call for server processing, the choice comes down to price and to whether your users' data leaves their machine. Updog Importer is built for that case.