Validate CSV Data Before Inserting It Into Your Database

A CSV file being parseable does not make its data valid.

If your application expects:

email       required email
age         number
signupDate  date
plan        free | pro | business

a spreadsheet can still contain:

bob.gmail.com
twenty six
32/99/2026
enterprise-premium-ultra

The safest place to discover those problems is before your backend starts writing records.

Validate at the import boundary

A useful import flow should validate rows after column mapping and before onComplete() returns normalized data to your application.

That gives the user immediate feedback, for example:

Row 14 · Email · bob.gmail.com · Invalid email address
Row 28 · Plan · Enterprise Premium · Must be one of the allowed values

The person who owns the spreadsheet can fix the problem while they still have the context to understand it.

Your database does not need to become the error-message generator.

Validation is more than “is this value empty?”

For a small SaaS, the useful production core is usually straightforward:

required fields
strings
numbers (including currency, percentages, and EU decimals)
dates (ISO plus MDY or DMY slash dates)
email addresses (including mailto: and Name <addr>)
enumerated values
in-file uniqueness via unique or duplicateKey

That covers a surprising amount of real import work. (In Bootstrapware these map to field types string, number, date, email, enum with enumValues, boolean, and url, plus optional unique and component props dateOrder / numberLocale.)

The complexity is not necessarily the validation rule itself. It is presenting hundreds of row-level results in a way that does not make the customer regret clicking Import.

The backend still validates too

Client-side import validation is not a substitute for server-side validation.

Your backend should still enforce authorization, business rules, uniqueness constraints, and whatever else protects your application.

The importer solves a different problem: catch predictable spreadsheet errors early and present them to the user in a useful form.

That means the final architecture remains clean:

Spreadsheet
  → browser-side import + validation
  → normalized rows
  → your backend
  → server-side business validation
  → database

Invalid rows should be explainable

A production import experience should not end with “Import failed.”

If 997 rows are fine and three are broken, the user should know which three and why.

Bootstrapware Importer is built around row preview, inline errors, and failed-row export (import-errors.csv) so the customer can see what needs attention without emailing you a spreadsheet and asking why your feature does not work.

That last part alone can be worth not building this yourself.