JavaScript Truthy and Falsy: A Deep Dive

Working with JavaScript’s truthy and falsy values used to trip me up. Sure, I knew the basics - false is falsy, true is truthy. But the edge cases? Those were tricky. Let’s dive into what I’ve learned about this fundamental yet often misunderstood concept.

The Eight Falsy Values

In JavaScript, there are exactly eight falsy values. Everything else is truthy. Here they are:

The Edge Cases That Break Your Brain

Type coercion in JavaScript creates some truly mind-bending scenarios.

The empty array comparison [] == false evaluates to true, yet an empty array is actually truthy. This happens because JavaScript first converts the array to a primitive value. When an empty array is converted to a primitive, it becomes an empty string. That empty string then converts to 0, and 0 == false is true. Yes, really.

Non-empty arrays like [1,2] == true evaluate to false through a similar conversion maze. The array [1,2] becomes the string "1,2" when converted to a primitive. This string can’t be cleanly converted to a number, so it becomes NaN. And NaN == true is false. The fact that [1,2] is truthy when used in an if statement doesn’t help it equal true in this comparison.

Objects throw another curveball. {} == false is false because an empty object converts to "[object Object]" when coerced to a primitive. This string can’t be converted to a number, so it becomes NaN, making the comparison false. Yet new Boolean(false) creates a Boolean object wrapping the value false, which bizarrely equals false when compared with ==, even though the Boolean object itself is truthy in conditional statements.

String comparisons add their own layer of confusion. "0" == false is true because the string "0" gets converted to the number 0, which equals false after type coercion. However, "false" == false is false because the string "false" can’t be converted to a number - it becomes NaN, making the equality check fail. The string content being “false” is irrelevant to the actual boolean value false.

These quirks explain why the strict equality operator (===) is generally preferred - it avoids this type coercion chaos entirely. But understanding these edge cases remains crucial for debugging legacy code or working with systems where loose equality is still in use.

Here’s a deceptively simple authentication check that could cause issues in production:

This code has two significant problems. First, If user is undefined, accessing user.loggedIn throws a TypeError. Secondly, The function returns whatever value is in loggedIn directly - could be 0, '', undefined, null, or any other value. The type coercion would actually happen at the call site, not in this function.

A more robust implementation handles these edge cases explicitly:

The improved version first checks if user exists, preventing the TypeError. Then it explicitly converts user.loggedIn to a boolean with Boolean(), making the intention clear and avoiding unexpected type coercion. This pattern is particularly important in authentication flows where ambiguity can lead to security issues.

Best Practices I’ve Learned

Type coercion affects code in surprising ways. Here are patterns I use to prevent bugs:

The optional chaining (?.) here prevents crashes when user is null or undefined. Without it, user.role would throw a TypeError. The ! operator then handles these cases:

• null or undefined user → returns ‘guest’
• user.role is undefined → returns ‘guest’
• user.role is empty string → returns ‘guest’
• user.role is 0 → returns ‘guest’
• user.role has value → returns that value

Array Length Validation

This seemingly simple function handles several edge cases:

• items is undefined → returns false
• items is null → returns false
• items is [] → returns false (length is 0)
• items is [1,2,3] → returns true (length is 3).

The Boolean() conversion ensures we always return a true boolean instead of a number.

Number Validation

This function catches common numeric pitfalls:

• "123" → returns false (string)
• undefined → returns false
• NaN → returns false
• 0 → returns true
• 100 → returns true

The typeof check ensures we have an actual number, not a string or other type that might coerce to a number.

Safe Configuration Object

The nullish coalescing operator (??) here is great because it only falls back to the default when a value is null or undefined

• settings is undefined → uses all defaults
• settings.theme is "" → keeps empty string (unlike ||)
• settings.timeout is 0 → keeps 0 (unlike ||)
• settings.retries is null → uses default 3
• settings.retries is undefined → uses default 3

The combination of ?. and ?? makes this function extremely robust - it will never throw and always returns a complete config object, while still respecting intentionally set falsy values.

Note: If you’re not familiar with the nullish coalescing operator (??), you can read more about it at JavaScript Operators: ’||’ vs ’&&’ vs ’??’

Key Takeaways for Working with Truthy/Falsy

JavaScript’s type coercion doesn’t have to be a source of bugs. Here’s what matters:

Next time you’re debugging a mysterious boolean condition or writing a validation function, remember: being explicit about your intentions with types will save you hours of debugging later.