JavaScript Type Coercion — Why '149.99' + Tax Broke It

JavaScript's type system is one of the most misunderstood parts of the language, and for good reason — it has genuine quirks that exist for historical reasons. Type coercion, the null/undefined split, and typeof's inconsistencies have tripped up millions of developers.

The good news is that once you understand the system on its own terms, it makes sense. This guide covers all 8 types, how typeof works, what coercion does, and how to write code that does not fall into the common traps.

Why JavaScript's Type System Is a Minefield

JavaScript's type system is dynamically typed with implicit coercion, meaning values are automatically converted between types during operations. This is not a bug — it's a design choice that trades compile-time safety for runtime flexibility. The core mechanic: when operators encounter mismatched types, the engine applies a set of precedence rules to coerce one or both operands into a common type before evaluation. The most notorious example is the + operator: if either operand is a string, it concatenates; otherwise, it performs numeric addition. This leads to '149.99' + 0.13 producing '149.990.13', not 150.12. In practice, the coercion rules follow a strict order: ToPrimitive → ToNumber → ToString, with object types triggering valueOf() or toString() first. The key property: loose equality (==) triggers coercion, while strict equality (===) does not. This matters because real systems fail silently — a tax calculation that concatenates instead of adds produces a string, which then propagates through downstream logic, corrupting totals, reports, and database writes. Understanding coercion is not optional; it's the difference between a reliable financial calculation and a silent data corruption bug.

The 8 JavaScript Types

JavaScript groups data into two camps: primitives (immutable, passed by value) and objects (mutable, passed by reference). There are 7 primitive types: string, number, boolean, null, undefined, Symbol, BigInt. Everything else is an object — including arrays, functions, dates, and plain objects. This split is the foundation of how JavaScript behaves.

// Primitives — immutable values
const str     = 'TheCodeForge'          // string
const num     = 42                       // number (no separate int/float)
const float   = 3.14                     // also number
const bool    = true                     // boolean
const nothing = null                     // null (intentional absence)
let  undef                               // undefined (not yet assigned)
const sym     = Symbol('id')             // Symbol (unique, no two are equal)
const big     = 9007199254740993n        // BigInt (integers beyond 2^53)

// Object — everything else
const obj  = { name: 'Alice', age: 30 } // plain object
const arr  = [1, 2, 3]                  // array (is an object)
const fn   = function() {}              // function (is an object)
const date = new Date()                 // Date (is an object)

console.log(typeof str)   // 'string'
console.log(typeof num)   // 'number'
console.log(typeof null)  // 'object'  ← historic bug, not a real object
console.log(typeof arr)   // 'object'
console.log(typeof fn)    // 'function' ← special case for functions

null vs undefined

Both mean 'no value' but they mean it in different ways. undefined is the language's own 'not set yet'. null is your explicit signal that something was intentionally cleared. This distinction is crucial for debugging and for writing clean APIs.

// undefined — the JS engine's default for 'not assigned'
let user;
console.log(user);             // undefined
console.log(user === undefined); // true

function greet(name) {
  console.log(name);           // undefined if called with no argument
}
greet();                       // undefined

// null — your code saying 'intentionally empty'
let currentUser = null;        // logged out — no user

// The null check gotcha
console.log(null == undefined);  // true  — loose equality
console.log(null === undefined); // false — strict equality (different types)

// Best practice: always use === and check explicitly
if (currentUser === null) {
  console.log('User logged out');
} else if (currentUser === undefined) {
  console.log('User state not initialised');
}

Type Coercion — Where Bugs Hide

JavaScript automatically converts types in certain contexts. This is called implicit coercion. It is the source of most JS type bugs. The + operator is particularly dangerous: if either operand is a string, it concatenates. The - operator coerces both to numbers. Loose equality (==) also coerces, which is why it's almost always better to use strict equality (===).

// + operator: if either operand is a string, concatenates
console.log(1 + '2')    // '12' — number coerced to string
console.log('3' - 1)    // 2    — string coerced to number
console.log(true + 1)   // 2    — true coerced to 1
console.log(false + 1)  // 1    — false coerced to 0

// == (loose) vs === (strict)
console.log(0 == false)  // true  — coercion
console.log(0 === false) // false — no coercion
console.log('' == false) // true  — both coerce to 0
console.log('' === false)// false

// The fix: always use === for comparisons
// Use explicit conversion when you mean to convert
const input = '42';  // string from a form input
const value = Number(input);  // explicit — clear intent
console.log(value + 1);  // 43, not '421'

Checking Types Reliably

typeof works well for primitives (with the null exception). For objects, you need additional tools: Array.isArray() for arrays, instanceof for prototype chains, and Object.prototype.toString for a precise type tag.

// For primitives: typeof works (except null)
function typeOf(val) {
  if (val === null)            return 'null';     // fix the null bug
  if (Array.isArray(val))     return 'array';    // typeof [] === 'object'
  return typeof val;
}

console.log(typeOf(null))      // 'null'
console.log(typeOf([1,2,3]))   // 'array'
console.log(typeOf('hello'))   // 'string'
console.log(typeOf(42))        // 'number'
console.log(typeOf({}))        // 'object'

// For objects: instanceof or Object.prototype.toString
console.log([] instanceof Array)    // true
console.log({} instanceof Object)   // true
console.log(Object.prototype.toString.call([]))  // [object Array]

Symbol and BigInt — The Less Common Types

Symbol (ES6) creates unique, immutable identifiers. Two Symbols with the same description are never equal. BigInt (ES2020) lets you work with integers beyond Number.MAX_SAFE_INTEGER (2^53 - 1). They're less common but essential for advanced scenarios: Symbols for property keys that won't collide, BigInt for high-precision arithmetic like financial systems or 64-bit IDs.

// Symbol — guaranteed unique
const sym1 = Symbol('id');
const sym2 = Symbol('id');
console.log(sym1 === sym2); // false — even with same description

// Use case: metadata on objects without collision
const metadataKey = Symbol('metadata');
const user = { name: 'Alice', [metadataKey]: { created: '2025-01-01' } };
console.log(user[metadataKey]); // { created: '2025-01-01' }

// BigInt — large integers
const big1 = 9007199254740993n;          // n suffix
const big2 = BigInt('9007199254740993'); // from string
const sum = big1 + 1n;                  // 9007199254740994n
// Mixing BigInt and Number throws TypeError
// BigInt('1') + 1  // TypeError: Cannot mix BigInt and other types

// BigInt is not strictly equal to Number
console.log(1n == 1);  // true  (loose, coercion allowed? Actually 1n == 1 is true)
console.log(1n === 1); // false (different types)

Primitive vs Reference — The Memory War You Didn't Know You Were Fighting

Every variable you declare boils down to one thing: where its value lives in memory. Primitives (strings, numbers, booleans, null, undefined, symbol, bigint) are stored directly on the stack. When you copy a primitive, you get a brand-new, independent copy. Change one, the other stays untouched.

Objects, arrays, and functions live on the heap. Variables hold a pointer to that heap location—a reference, not the data itself. Copying an object doesn't clone it; you just get another pointer to the same spot. Mutate one variable's object and every other pointer sees the change. This is why your state managment library zeros in on immutable patterns: they avoid this shared-memory nightmare.

The production takeaway: always assume object copies are shallow. Use structuredClone() or spread operators deliberately. Never mutate function arguments that are objects unless you're ready for side effects that'll haunt your Friday deployment.

// io.thecodeforge — javascript tutorial

let itemA = 'book';
let itemB = itemA;
itemB = 'lamp';
console.log(itemA); // still 'book'

let userA = { role: 'admin' };
let userB = userA;
userB.role = 'viewer';
console.log(userA.role); // 'viewer' — oops

// Safe copy
let userC = { ...userA, role: 'admin' };
console.log(userC.role); // 'admin'

typeof Is a Liar — Here's What Actually Works for Type Checks

typeof screams 'object' for null, arrays, dates, and regexes. That's not useful—it's a trap. Null is a primitive with its own type, but typeof null === 'object' is a bug from JavaScript's first day that will never be fixed. Arrays aren't objects for iteration purposes; they're arrays. You need real detection.

For strict primitive checks, use Object.prototype.toString.call(). It returns strings like '[object Array]' or '[object Null]', and it never lies. Pair it with a small utility: typeOf(value) that strips the noise. For arrays, Array.isArray() is your friend—works cross-realm, even across iframes. For plain objects, check Object.getPrototypeOf(value) === Object.prototype.

Don't rely on duck-typing in critical paths. When an API returns a payload, validate the types before you operate. One unexpected null slipping through typeof costs you a 'Cannot read properties of null' stack trace at 3 AM.

// io.thecodeforge — javascript tutorial

function trueType(value) {
  return Object.prototype.toString.call(value).slice(8, -1);
}

console.log(trueType(null));        // Null
console.log(trueType([]));          // Array
console.log(trueType(new Date()));  // Date
console.log(trueType({}));          // Object

// Real-world guard
function processPayload(payload) {
  if (trueType(payload) !== 'Object') {
    throw new Error('Expected object payload');
  }
}

Keyed Collections: When Objects Lie

Objects force all keys to strings, so obj[true] becomes obj['true'] and obj[{}] becomes obj['[object Object]']. This breaks any code relying on numeric or object keys. Maps and Sets fix this with zero coercion. Use a Map when you need keys of any type—numbers, objects, even NaN—and need predictable insertion order. Use a Set when you only care about unique values, not keys. WeakMap and WeakSet are the memory-safe siblings: they hold weak references to objects, which means if no other code references a key, the garbage collector can reclaim it. This prevents memory leaks in long-running apps. The catch: WeakMaps aren't iterable. You can't .forEach or get their size. They're purpose-built for private data or DOM node metadata—never for general iteration.

// io.thecodeforge — javascript tutorial

const visits = new WeakMap();
const user = { id: 1 };
visits.set(user, 42);

user = null; // WeakMap entry auto-collected

const uniqueTags = new Set();
uniqueTags.add('js');
uniqueTags.add('js'); // ignored — already present

console.log(uniqueTags.size); // 1

Interesting Facts About Data Types

JavaScript’s type system hides chaos behind a clean syntax. typeof null returns 'object' — a bug from the first spec that can’t be fixed without breaking millions of sites. NaN is the only value not equal to itself: NaN !== NaN is true. Arrays are objects: typeof [] returns 'object'. That’s why Array.isArray() exists. Strings are primitive but behave like objects because JS autoboxes them with temporary wrapper objects. This is why 'hello'.length works — JS creates a String object, reads .length, then discards it. BigInt can’t mix with regular numbers: 1n + 1 throws a TypeError. undefined is a global variable that can actually be assigned (in old JS), while null is a keyword. The classic interview trap: 0.1 + 0.2 !== 0.3 — all numbers are IEEE 754 doubles, so decimal math is imprecise by design.

// io.thecodeforge — javascript tutorial

console.log(typeof null);                // 'object'
console.log(NaN === NaN);                // false
console.log(Array.isArray([]));          // true
console.log(0.1 + 0.2 === 0.3);          // false
console.log(typeof 42n);                 // 'bigint'

// Autoboxing demo
const s = 'hello';
s.customProp = true;
console.log(s.customProp);              // undefined — object was temporary

Summary

JavaScript's type system is deceptive at every turn. What appears to be a simple 'number' can silently overflow into a BigInt, and what looks like a string can coerce into NaN during runtime. The core tension lies between primitive immutability (undefined, null, Boolean, Number, String, Symbol, BigInt) and reference mutability (Object, Array, Function, Date, RegExp, Set, Map, WeakMap, WeakSet). Memorable rules: null is an object (by spec bug), undefined is a global property, and type coercion is never 'helpful'—it's a source of production bugs. Always use strict equality (===) for comparisons, check types with Object.prototype.toString.call(value) for reliability, and treat mutable objects as stateful hazards. The language punishes assumptions; the only safe approach is explicit type handling and defensive coding around falsy values, NaN, and unexpected reference mutations.

// io.thecodeforge — javascript tutorial
// Summary: type system rules in practice
function safeType(x) {
  return Object.prototype.toString.call(x).slice(8, -1);
}

const examples = [
  undefined,
  null,
  true,
  42n,
  Symbol('id'),
  {},
  [],
  new Map()
];

examples.forEach(v => console.log(safeType(v)));
// Output: Undefined, Null, Boolean, BigInt, Symbol,
//         Object, Array, Map

Real-World Type Gotchas

Beyond the textbook types, JavaScript punishes developers with edge cases that burn production systems daily. Array.isArray() is your only reliable way to detect arrays—typeof returns 'object'. NaN !== NaN, so you need Number.isNaN() for that check. Type coercion in comparisons: [] == false evaluates to true (empty array becomes empty string, then 0, then false), but [] == ![] is also true (truth table loophole). The infamous 'parseInt(0.0000005)' returns 5 because the string becomes '5e-7' and parseInt stops at '5'. Always pass radix: parseInt(x, 10). For BigInt, mixing with regular Number types throws TypeError—you cannot add 1n + 1. These nine gotchas account for 70% of type-related bug reports in production JavaScript. Know them, and you'll save hours of debugging.

// io.thecodeforge — javascript tutorial
// Production gotchas exposed
const arr = [];
console.log(typeof arr); // 'object' — useless
console.log(Array.isArray(arr)); // true — use this

console.log(NaN === NaN); // false
console.log(Number.isNaN(NaN)); // true

// Coercion landmine
console.log([] == false); // true
console.log([] == ![]); // true

// parseInt quirk
console.log(parseInt(0.0000005)); // 5 — watch for scientific notation