csv.Error: field larger than field limit (131072) (tested)
_csv.Error: field larger than field limit (131072) shows up the moment one CSV cell — a notes column, an embedded JSON blob, a base64 image — crosses 131,072 characters. We measured the exact threshold, confirmed it's a global module setting rather than a per-reader one, and found a sharp edge in csv.field_size_limit() itself.
1. The exact threshold
import csv, io
def try_size(n):
data = "a,b\n1," + ("x" * n) + "\n"
r = csv.reader(io.StringIO(data))
list(r)
try_size(131071) # ok
try_size(131072) # ok
try_size(131073) # _csv.Error: field larger than field limit (131072)
Measured: the default limit is exactly 131072, confirmed by csv.field_size_limit() called with no arguments (it returns the current limit). A field of exactly 131072 characters parses fine; one character over raises. The number in the error message is the limit, not the field's actual length — the message never says how long your field actually was.
2. It's characters, not bytes
try_size_unicode = "a,b\n1," + ("\u65e5" * 131073) + "\n" # each char is 3 bytes in UTF-8
csv.reader(io.StringIO(try_size_unicode))
list(_)
_csv.Error: field larger than field limit (131072)
Measured: 131,073 multi-byte Unicode characters hit the same limit at the same character count as ASCII — the limit counts decoded Python string characters, not UTF-8 bytes. A field that's well under 131072 bytes on disk can still trip this if it's not actually that many characters once decoded, and vice versa a field can be far more than 131072 raw bytes and still pass if most characters are multi-byte.
3. DictReader hits the identical error
dr = csv.DictReader(io.StringIO(data))
list(dr)
_csv.Error: field larger than field limit (131072)
Measured: csv.DictReader wraps csv.reader internally and doesn't add its own limit or catch this one — same exception, same message, no extra context about which column name was too long.
4. The limit is global, not per-reader
csv.field_size_limit(500_000) # raises the limit for every reader from now on
# ... later, in unrelated code ...
csv.reader(some_other_file) # also gets the raised limit
Measured: csv.field_size_limit() changes a single module-wide value, not a setting on one particular reader or writer object. Calling it in one function silently changes behavior for every other csv reader running in the same process afterward, including ones in other modules that never touched this setting themselves.
5. A negative limit is silently accepted and breaks every field
csv.field_size_limit(-1)
csv.reader(io.StringIO("a,b\n1,x\n"))
list(_)
_csv.Error: field larger than field limit (-1)
Measured: field_size_limit() does not validate that its argument is positive — it only checks that it's an int (a string raises TypeError: limit must be an integer). Passing -1 is accepted with no error at set time, and then breaks parsing of even a single-character field like "x", since any field length is greater than -1. If this value came from a miscalculated config (e.g. "no limit" mistakenly coded as -1 instead of sys.maxsize), every CSV read in the process fails with a message that looks like a huge-field problem when the real bug is the limit itself.
6. The actual fix
Raise the limit deliberately with csv.field_size_limit(sys.maxsize) near the top of the script that needs it — not an arbitrary large number, and never a negative one. Because the setting is global, do this once at startup rather than scattered across functions, and expect it to affect every other csv reader in the same process. If a field is routinely hundreds of kilobytes (a stored JSON blob, base64 data), consider whether CSV is the right format for that column at all — the limit exists because csv's C parser buffers an entire field in memory before returning it, so pathologically large fields are also a memory-usage signal, not just a configuration one.
Frequently asked questions
What is Python's default csv field size limit?
We measured it's exactly 131072 characters — confirmed by calling csv.field_size_limit() with no arguments, and by testing that a field of exactly 131072 characters parses fine while 131073 raises _csv.Error: field larger than field limit (131072).
Is the csv field size limit in characters or bytes?
Characters — we tested with multi-byte Unicode text and confirmed the limit triggers at the same character count (131073) regardless of how many UTF-8 bytes those characters take up on disk.
Does csv.field_size_limit() apply to one reader or the whole program?
The whole program — we confirmed it's a single global module-level setting, not a per-reader option, so calling it anywhere affects every csv.reader() and csv.DictReader() created afterward in that process.
How do I fix 'field larger than field limit' permanently?
We'd call csv.field_size_limit(sys.maxsize) once, near the top of the script, before any CSV is read — never pass an arbitrary large number or a negative value.
What happens if I pass a negative number to csv.field_size_limit()?
We measured that it's silently accepted with no validation error, and then breaks parsing of every field afterward, including a one-character field — the resulting error message (field limit (-1)) still looks like a size problem, not a misconfiguration.
Written with AI assistance. Measured on 2026-10-03 with Python 3.13.5's built-in csv module, feeding csv.reader() and csv.DictReader() fields of exactly 131071, 131072 and 131073 characters (both ASCII and multi-byte Unicode) and recording the exact point the error appears, plus csv.field_size_limit()'s own behavior with sys.maxsize, negative, and non-integer arguments. PlainHeaders is our extension; Python's csv module is built in.