CSV Field Length Exceeded: Fix 'Value Too Long for Column' Import Errors

Quick Answer

"Value too long for column" errors mean a CSV field contains more characters than the database column or CRM field allows. The error tells you the column name and the limit — it doesn't tell you which row. The fix is to find the maximum-length value in that column, then either truncate it to fit or expand the column definition.

The fix: Run SELECT MAX(LENGTH(column_name)) FROM table_name (after a partial import) or search the CSV directly for values exceeding the limit before importing.

Why it happens: Column definitions in databases and CRM systems have character limits. A VARCHAR(100) column can hold at most 100 characters. An address field exported from one system with 350-character descriptions can't fit into another system's 255-character limit.

---

What the Error Messages Actually Mean

ERROR: value too long for type character varying(N) (SQL state: 22001) — PostgreSQL. A text value in your CSV exceeds N characters. The error reports the column name and limit but not the row number.

SQL Error [1406] [22001]: Data too long for column 'X' at row 1 — MySQL/MariaDB. The "row 1" is misleading — MySQL doesn't report the actual row; it always shows "row 1." The problem is somewhere in your file, not necessarily the first row.

_csv.Error: field larger than field limit (131072) — Python's csv module. One of your fields contains more than 128KB of text. This is Python's soft limit, not a database constraint — it protects against malformed CSV files that accidentally read a huge section as one field (usually caused by an unclosed quote).

"Field Validation Error: value exceeds maximum length of N characters" — Salesforce, HubSpot, Zoho. CRM field character limits are typically 255 characters for text fields, though some fields are shorter.

Value too long: column 'notes' exceeds 1000 chars — Generic CRM or ERP limit. Notes and description fields often have limits of 1,000–2,000 characters.

---

Fast Fix (2 Minutes)

If you know the column causing the error:

1. Find the max length in that column — In Excel: =MAX(LEN(A2:A5000)) in a helper column. Identifies the longest value.
2. Find which row it's in — =MATCH(MAX(LEN(A2:A5000)),LEN(A2:A5000),0)+1 returns the row number.
3. Decide: truncate or expand — If the database column can grow, ALTER the column. If not, truncate the long values.
4. Re-import — A single pass after finding the max usually clears the error.

For the Python field larger than field limit error:

import csv
import sys
csv.field_size_limit(sys.maxsize)

Add this before your CSV reading code. It raises the soft limit to the system maximum.

If you don't know which column is causing it, continue below.

---

TL;DR: Field length errors hide the offending row number. The two fastest ways to find it: =MAX(LEN()) in Excel on each column, or SplitForge Data Validator which scans every column and flags values exceeding a specified limit. Fix by truncating the value, expanding the column, or splitting long text into separate fields.

---

You've set up a PostgreSQL table to store customer records. You run the COPY command. Six seconds later: ERROR: value too long for type character varying(100) CONTEXT: COPY customers, line 1, column notes: "The client has been with us since 2019 and requires spe...". The error tells you the column. It doesn't tell you which row among your 8,000 rows has the problem — or whether there are 47 more rows with the same issue.

Field length errors are rarely a single-row problem. A description field that hits the limit in row 312 probably hits it in 30 other rows too. Fix them all before re-importing.

Each error was reproduced using PostgreSQL 16, MySQL 8.0, and Python's csv module, March 2026.

---

---

Table of Contents

• Fix 1: Find the Offending Row (PostgreSQL)
• Fix 2: Find the Offending Row (MySQL)
• Fix 3: Python csv Module Field Limit
• Fix 4: CRM Field Length Limits
• Fastest Method (For Large Files)
• Fix 5: Expand vs Truncate — Which to Choose
• Finding Long Values Before Importing
• Additional Resources
• FAQ

---

This guide is for: Database administrators, data engineers, and CRM admins dealing with field length errors during CSV import. Basic SQL knowledge is assumed for database-specific fixes.

---

Fix 1: Find the Offending Row (PostgreSQL)

PostgreSQL reports the column name and limit but not the row number. Two approaches to find it.

Approach A — Import to a wide staging table first:

Create a staging table where every column is TEXT (unlimited length). Import the CSV into the staging table successfully. Then query for oversized values:

-- Find all rows where 'notes' exceeds 100 characters
SELECT ctid, notes, LENGTH(notes) as len
FROM staging_customers
WHERE LENGTH(notes) > 100
ORDER BY len DESC;

This tells you exactly which rows have the problem and how long each value is. Fix those rows in the CSV, then import to the real table.

Approach B — Query max length after defining a larger column:

If the column limit is the problem (not the data), check what the actual maximum length in your data is:

SELECT MAX(LENGTH(notes)) as max_len,
       COUNT(*) FILTER (WHERE LENGTH(notes) > 100) as rows_over_limit
FROM staging_customers;

If max_len is 324 and your column is VARCHAR(100), you have two choices: truncate all values to 100 characters, or change the column to VARCHAR(350).

Expanding the column:

ALTER TABLE customers ALTER COLUMN notes TYPE VARCHAR(500);

Then re-run the COPY. No data loss.

Truncating at import:

INSERT INTO customers (id, name, notes)
SELECT id, name, LEFT(notes, 100)
FROM staging_customers;

Fix 2: Find the Offending Row (MySQL)

MySQL's error message always says "at row 1" even when the problem is at row 8,432. This is because MySQL reports the row within the current batch, not the overall file position.

❌ BROKEN (MySQL error — row number is meaningless):
SQL Error [1406] [22001]: Data too long for column 'description' at row 1

This means: somewhere in your CSV, a value in 'description' exceeds the column limit.
"at row 1" does NOT mean the first row is the problem.

FIXED (find actual rows before importing):
SELECT MAX(LENGTH(description)) FROM staging_table;
-- Returns: 847
-- Your column is VARCHAR(255) → 847 > 255 → that's the problem

MySQL's silent truncation behavior:

By default (without strict mode), MySQL silently truncates values that are too long rather than throwing an error. This is dangerous — your data loads successfully but is cut off mid-sentence. Values like "The customer requires special handling for their account due t" in a 60-character field mean the last 200+ characters of every long note are permanently lost.

To enable strict mode (recommended):

SET SESSION sql_mode = 'STRICT_TRANS_TABLES';

With strict mode on, MySQL throws an error instead of silently truncating. This is safer — you catch the problem before data is lost.

Fix 3: Python csv Module Field Limit

Python's built-in csv module has a default field size limit of 131,072 bytes (128KB). Any individual field larger than this raises _csv.Error: field larger than field limit (131072).

This limit exists to protect against malformed CSV files — specifically, unclosed quotes that would cause the parser to read thousands of rows as a single field.

The most common real cause: An unclosed quote in a description or notes field. The parser starts reading a "field" that is actually the rest of the file.

Check for unclosed quotes first:

❌ BROKEN (unclosed quote causes massive "field"):
id,name,description
1,Alice,"Great customer who needs special handling
2,Bob,Standard account
3,Carol,Priority client

The opening quote on row 1 is never closed.
Python reads everything from row 1 to end-of-file as one field.
Result: "field larger than field limit"

FIXED:
id,name,description
1,Alice,"Great customer who needs special handling"
2,Bob,Standard account
3,Carol,Priority client

If the field genuinely contains >128KB of text, raise the limit:

import csv
import sys

# Raise to system maximum
csv.field_size_limit(sys.maxsize)

# Then read normally
with open('your_file.csv', newline='') as f:
    reader = csv.reader(f)
    for row in reader:
        # process rows

Fix 4: CRM Field Length Limits

CRM systems have field-level character limits that are configured in the platform, not in your CSV. Importing a value that exceeds the limit fails silently (the row is skipped) or with a vague field validation error.

Common CRM field limits:

Finding oversized values before importing to a CRM:

Use SplitForge Data Validator to specify a maximum character length per column and flag every value that exceeds it. This runs locally in your browser — your CRM data never leaves your machine during validation.

For Salesforce specifically, export your field definitions from Setup → Object Manager → [Object] → Fields & Relationships to get exact limits before building your import CSV.

---

Fastest Method (For Large Files)

If your file has more than 50,000 rows and you need to find and fix field length violations fast, skip Excel. This is the direct path:

Step 1: Import everything to a staging table with no length constraints.

CREATE TABLE staging_import (
  id TEXT,
  name TEXT,
  description TEXT,
  notes TEXT
  -- Use TEXT for every column — no length limits
);

COPY staging_import FROM '/path/to/your.csv'
  WITH (FORMAT csv, HEADER true);

Import succeeds because TEXT columns have no length ceiling. Every row lands.

Step 2: Find every row violating your target limits.

SELECT
  ctid AS row_id,
  id,
  LENGTH(description) AS description_len,
  LEFT(description, 80) AS description_preview
FROM staging_import
WHERE LENGTH(description) > 255
   OR LENGTH(notes) > 500
ORDER BY LENGTH(description) DESC;

This returns every offending row in seconds, ranked by severity. No guessing.

Step 3: Export offending rows to a CSV for manual review.

COPY (
  SELECT * FROM staging_import
  WHERE LENGTH(description) > 255
) TO '/path/to/oversized_rows.csv'
WITH (FORMAT csv, HEADER true);

You now have an isolated file of only the rows that need fixing.

Step 4: Fix the values and re-import only the corrected rows.

Open oversized_rows.csv, truncate or correct the long values, save. Then update the staging table:

-- Or re-import to staging and run UPDATE to merge fixes
UPDATE staging_import s
SET description = f.description
FROM fixed_rows f
WHERE s.id = f.id;

Step 5: Insert from staging to your real table.

INSERT INTO real_table
SELECT * FROM staging_import;

This will fail cleanly if any value still exceeds the column limit — no partial imports, no silent truncation.

Total time for a 500,000-row file: under 10 minutes, including the fix pass. The same workflow in Excel would take hours and risk silent truncation without any row-level audit trail.

---

Fix 5: Expand vs Truncate — Which to Choose

When you find values that are too long, you have two options. The right choice depends on whether the extra characters matter.

Expand the column when:

• The data is accurate and the limit is arbitrary (a legacy column that was set to VARCHAR(100) because "nobody writes more than 100 characters")
• You control the database schema
• The extra characters contain meaningful information (the 200-character product description is correct; the column was just defined too narrow)

Truncate when:

• The limit is enforced by the platform (CRM field limits you can't change)
• The extra characters are meaningless (trailing whitespace, repeated punctuation, exported formatting)
• The first N characters are a complete, meaningful sentence

Never truncate silently. If you truncate, mark the rows you truncated. A notes_truncated boolean column, or a log file listing row IDs and original lengths, lets you identify which records need manual review after import.

---

Finding Long Values Before Importing

The fastest pre-import approach: check maximum field lengths in your CSV before touching the database.

In Excel:

1. Add a helper column: =LEN(A2) where A2 is the first data cell.
2. Copy down to all rows.
3. =MAX(helper_column) gives the longest value.
4. =MATCH(MAX(helper_column),helper_column,0)+1 gives the row number.

Repeat for each column that's failing.

In a text editor:

For large files where Excel is slow, open in VS Code and use the column selection and find features to spot long lines.

With SplitForge:

SplitForge Data Validator checks every column simultaneously and flags values exceeding a specified character limit, with row numbers and current lengths in a downloadable report. Processes locally — your data never uploads.

Most cloud-based CSV tools upload your file to a remote server to check field lengths. For files containing customer data, product descriptions, or internal notes, that upload is unnecessary exposure — GDPR Article 5(1)(c) requires data minimization, and uploading a file to validate it before import introduces an extra processing step that may not be necessary. Validating locally eliminates it entirely.

For the complete CSV import error reference, see our CSV import errors complete guide and the CSV data type mismatch fix guide.

Additional Resources

Database Documentation:

• PostgreSQL Data Types — character varying — Official VARCHAR behavior and limits
• MySQL String Data Types — VARCHAR, TEXT, and LONGTEXT limits
• PostgreSQL ALTER TABLE — How to expand column definitions

Standards:

• RFC 4180: CSV Format Specification — CSV structure reference
• Python csv module documentation — csv.field_size_limit() usage and parameters

FAQ