Both null and empty string are valid JSON values that can mean missing. The difference matters when the consumer treats them differently. SQL NULL is a distinct value with three-valued logic; SQL empty string is a string of zero characters that participates in normal string comparisons. JavaScript both null and empty string are falsy in boolean contexts but differ in JSON.stringify output and in equality checks. Picking the right representation for your context avoids subtle bugs where empty cells are interpreted inconsistently.
FixTools default rule is context-sensitive: numeric and boolean columns emit null for empty cells because there is no zero-value representation that means missing, while string columns emit empty string because that is the closer match for textual emptiness. This default works for most use cases but can produce inconsistency across columns. With Keep Nulls enabled, every empty cell becomes null regardless of column type, which is the cleaner choice when consistency matters more than the contextual nuance.
For database loads, Keep Nulls is usually the right choice because columns with NOT NULL constraints are checked against actual null values during INSERT. An empty string slips through a NOT NULL constraint because it is not null, but it may violate a CHECK constraint or business rule that requires non-empty values. By making missing data explicit as null, you can detect schema violations at load time rather than at query time.
For API contracts that specify null for missing fields, Keep Nulls is again the right choice. JSON Schema validation typically distinguishes type string from type null and complains if a field marked null is empty string. Producing null in the converter avoids these validation failures and matches the contract literally. The toggle costs nothing and the consistency is worth the keystroke.