Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Your code can tell a missing field from an empty value only if the data format, application, and storage layer preserve that distinction. A blank value describes what was submitted; “unanswered” describes what happened in a workflow. Unless your form or API records that workflow, the value alone may not reveal whether someone skipped a question, declined to answer, or never saw it.

What “blank” can mean in data

These representations are not interchangeable:

Representation What it tells your code
Missing property The object contains no key with that name.
null The property exists and has an explicit null value.
Empty string ("") The property contains a string with no characters.
Whitespace-only string The property contains a string, but its characters are spaces or other whitespace.
Empty collection ([]) The property contains a collection with no items.
Nonempty value The property contains data, though that data still needs type and content validation.

JSON Schema explains that a property whose value is null is not equivalent to a property that is absent. Its object reference also treats presence and type as separate concerns: a required property must be present, and a present null does not meet a string type unless the schema allows null.

That distinction appears in other systems too. Section 4.5 of IETF RFC 9051 defines IMAP’s NIL as a nonexistent data item and distinguishes it from an empty string or empty list. This is a protocol-specific example, not a universal rule for every API.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Can you tell whether someone answered?

Not from “blank” alone. An empty string might be an intentional response; a missing property might mean “not supplied”; and a null might mean “clear this value.” Those are possible contract choices, not meanings every platform assigns automatically.

If the application needs to know whether a question was shown, skipped by conditional logic, intentionally declined, or left unanswered, record that workflow state explicitly. A stored empty value cannot reliably reconstruct the respondent’s path after the fact. MongoDB’s JSON Schema validation tips likewise distinguish missing fields from fields set to null; whether a document is accepted depends on the configured validation rules.

How to check a field without collapsing its meaning

  1. Check whether the key exists. Do this before reading, defaulting, or normalizing the value.
  2. Check the value’s type. If present, distinguish null, string, array, and other allowed types.
  3. Inspect content where relevant. For strings, decide whether an empty string and whitespace-only text count as blank; for collections, distinguish an empty collection from a missing one.
  4. Apply the contract’s rules. Validate requiredness and content separately. Permit null only when the schema says it is valid.
  5. Normalize at a deliberate boundary. Collapse states only after preserving any difference needed for validation, user intent, audit history, or later updates.

For an optional field, document what omission, null, and an empty string mean in your API or form schema. For example, omission could mean “not provided,” null could mean “explicitly clear,” and an empty string could mean “provided as blank.” Choose meanings that fit the application; do not assume they are universal. Create, update, and patch operations may need different rules.

Why form and validation frameworks matter

A value can change meaning as it moves through a form engine, serializer, validation framework, and database. Check each layer’s behavior rather than relying on truthiness or an assumption that all empty-looking values are equivalent.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

ODK: unanswered numbers and blank constraints

Open Data Kit’s Form Logic documentation says unanswered number questions are nil, and arithmetic involving an empty value yields NaN. ODK shows coalesce() and if() as explicit ways to substitute a value such as zero. That substitution is a form-design choice, not evidence that an unanswered number was actually zero.

ODK also says constraints are not evaluated when a response is blank. If a blank must be forbidden in an ODK form, its guidance is to make the question required. These behaviors are specific to ODK; verify how the form system you use handles unanswered fields.

ASP.NET Core: empty and whitespace-only strings

Microsoft’s ASP.NET Core 10.0 validation documentation says empty strings are converted to null by default during model binding, and whitespace-only input is considered invalid for a required string. Nullable reference type settings and model binding affect required-string validation, so check the application’s configuration and target framework. A value that arrives as null may have started as an empty string.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

How SQL databases treat null and empty strings

MySQL distinguishes SQL NULL from the empty string ''. Its Reference Manual notes that newcomers often mistake them for the same thing. The manual illustrates possible meanings with a phone number that is not known versus a person known to have no phone number; those interpretations are examples, not universal business rules.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

In MySQL, test for null with IS NULL, not = NULL. If an empty string is a valid stored state, compare it separately:

WHERE phone_number IS NULL
WHERE phone_number = ''

Choose the query that matches the state your application intends to find. Do not use numeric coercion or a language’s truthiness rules as a substitute for explicit checks.

A practical contract for forms and APIs

Before accepting or storing a field, decide which distinctions matter to the application and state them in the contract. A useful checklist is:

  • Does the field have to be present?
  • Is null a permitted value, and what does it mean here?
  • Is an empty string valid, invalid, or treated as equivalent to null?
  • Does whitespace-only text count as blank?
  • Is an empty array different from an omitted array?
  • Must the system record whether a question was presented, skipped, declined, or left unanswered?
  • Will any framework or database layer convert or collapse states before the application validates them?

Keep states distinct until the contract has enough information to validate them correctly. If the system stores only a blank value but later needs to explain a user’s action, the missing information must be captured separately when that action occurs.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.