Data Types and Type Coercion That Trips Beginners Up

Now that you can store values in variables, you need to understand what kinds of values JavaScript actually has, and how it quietly converts between them — because that quiet conversion is where a lot of beginner bugs come from.

JavaScript's Primitive Data Types

JavaScript has a handful of primitive types: string (text), number (both integers and decimals — JavaScript doesn't separate them), boolean (true or false), undefined (a variable that exists but has no value yet), and null (a deliberate "nothing" value you assign yourself). There's also object, which covers plain objects, arrays, and functions — we'll dig into those in upcoming lessons.

let name = "Vikesh Singh";
let age = 31;
let isPublished = true;
let middleName;
let noAvatar = null;
console.log(typeof name, typeof age, typeof isPublished, typeof middleName, typeof noAvatar);

That last line prints: string number boolean undefined object. Yes, typeof null returns "object" — that's a long-standing quirk in the language itself, not something you're doing wrong. It trips people up constantly, so just remember it as a fact about JavaScript rather than a logic puzzle to solve.

How Type Coercion Works

Now, the real topic of this lesson: type coercion. JavaScript is "loosely typed," meaning it will often try to convert values automatically rather than throw an error. This is convenient sometimes and dangerous other times.

console.log("5" + 3);
console.log("5" - 3);
console.log("5" * "2");
console.log(1 + "1");

Here's what actually happens, and why: the + operator means "add" for numbers but also means "concatenate" for strings. When either side of + is a string, JavaScript converts the other side to a string too. So "5" + 3 becomes "53", a string. But - and * have no meaning for text, so JavaScript tries to convert the string to a number first. "5" - 3 becomes 2, and "5" * "2" becomes 10. And 1 + "1" becomes "11", a string, for the same reason as the first example. The lesson: + is unpredictable with mixed types, but -, *, and / are fairly consistent because they almost always push toward numbers.

Loose Vs Strict Equality

This is exactly why comparing values safely matters. JavaScript has two equality operators: == (loose equality, allows coercion) and === (strict equality, checks type and value with no conversion).

console.log(0 == false);
console.log(0 === false);
console.log("" == 0);
console.log(null == undefined);
console.log(null === undefined);

0 == false is true because false gets coerced to 0 for the comparison. 0 === false is false, because one is a number and the other is a boolean — no conversion is allowed, so they're simply different types. "" == 0 is also true, for similarly surprising coercion reasons. null == undefined is true (a special case the language carves out just for these two), but null === undefined is false, since they are different types.

The practical rule that will save you real debugging time: always use === and !== instead of == and !=, unless you have a specific, well-understood reason not to. Strict equality removes an entire class of "why is this if-statement doing something weird" bugs before they happen.

Converting Values On Purpose

One more useful tool: converting values on purpose, instead of letting JavaScript guess.

console.log(Number("42"));
console.log(String(42));
console.log(Boolean(""));
console.log(Boolean("hello"));

Number("42") gives you 42 as an actual number. Boolean("") is false, and Boolean("hello") is true — this is because JavaScript treats certain values as "falsy" (0, "", null, undefined, NaN, false) and everything else as "truthy." You'll use this falsy/truthy idea constantly in conditionals in a later lesson.

Coercion With Form Input

One more coercion case worth knowing because it shows up constantly in real forms: values coming from an HTML input are always strings, even if the input type is "number". So if you read a price field and immediately try to add it to a number without converting first, you'll get string concatenation instead of addition, exactly like the "5" + 3 example above. The fix is always to explicitly convert with Number() or the unary plus shortcut (+inputValue) before doing math with any value that came from the page itself, rather than trusting it arrived as the type you expected.

A last practical habit: when you're debugging a value that seems wrong, check its type first with typeof before assuming the logic itself is broken. A huge share of real bugs in beginner JavaScript code are not wrong logic at all — they're a value being the wrong type going into otherwise correct logic, exactly like a number arriving as a string from a form field. Building the reflex to ask "what type is this actually" before anything else will save real debugging time across every lesson still ahead in this course.

It's also worth practicing the reverse direction: converting a number back into a readable string for display, since this comes up constantly once you start showing data on a page. String(1500) or `` both give you "1500" cleanly, but real display code often needs formatting too, like adding a currency symbol or limiting decimal places with toFixed(2) on a number before turning it into a string. Getting comfortable moving data between these types deliberately, in both directions, is exactly the skill this lesson is building toward.

Give it a try: open your browser console and test a few coercions yourself — try "10" == 10, "10" === 10, and [] == false. Predict the answer before you run it, then check. Being wrong on a few of these now is exactly how this sticks.