Escritos

La trampa de `==` y la coerción de tipos en JavaScript

¿Por qué `"" == 0` es true? ¿Por qué `[] == false` es true? ¿Y por qué `NaN == NaN` es false? Desmontamos el mecanismo más confuso de JavaScript, la coerción de tipos, y la única forma segura de escapar del lío.

Furkan Özay17 de septiembre de 2026 · 3 min de lectura
czCZAY.DEV // EDITORIALES
TYPE SYSTEM

#JavaScript · 3 MIN DE LECTURA

FURKAN ÖZAYVOL. 2026 // #26DE

Imagina tres líneas de código sencillas: ¿una cadena vacía es igual a cero ("" == 0)? ¿Un array vacío es igual a false ([] == false)? ¿Y NaN es igual a sí mismo (NaN == NaN)?

Cuando le haces estas preguntas a JavaScript con el operador == (igualdad laxa), las dos primeras devuelven true y la última devuelve false. Para hacerlo más raro, aunque una cadena vacía sea igual a cero, la cadena cero ("0") no es igual a una cadena vacía (""). ¿Y null == 0? False. Pero si compruebas null >= 0, el resultado es true.

A primera vista, estos resultados parecen completamente arbitrarios y rotos, pero aquí nada es realmente aleatorio. Cada uno sigue una regla documentada.

Algoritmo y coerción de tipos

El motor detrás de todas estas rarezas es la coerción de tipos. Cuando comparas dos valores con == y sus tipos son distintos, JavaScript los convierte internamente para llevarlos a un tipo común.

Toma [] == false, por ejemplo:

  • Primero false se convierte en número y pasa a ser 0. ([] == 0)
  • El array vacío ([]) se convierte en un valor primitivo, que da una cadena vacía (""). ("" == 0)
  • Después la cadena vacía se convierte en número y pasa a ser 0.
  • Por último, la comparación ejecuta 0 == 0, que se evalúa como true.

La única excepción a la coerción numérica estándar es null. Con la igualdad laxa (==), null solo es igual a undefined; no se convierte en número. En cambio, los operadores relacionales como >= (mayor o igual que) no hacen esa excepción y convierten null en cero. Por eso null == 0 es false, pero null >= 0 es true.

La regla y la solución

No tienes que memorizar cada paso de conversión ni cada caso límite. La solución se reduce a un solo hábito y una regla de oro: usa siempre el triple igual (===).

El operador triple igual (===) comprueba la igualdad estricta. Nunca convierte tipos. Si los tipos de ambos lados no coinciden, devuelve false de inmediato sin ejecutar ninguna conversión.

Solo hay una excepción práctica: cuando quieres comprobar a propósito null y undefined a la vez, escribir deger == null está bien. En cualquier otro lugar, ceñirte a === te ahorrará este dolor de cabeza.

Conclusión

Si quieres poner fin a los debates de "¿por qué se comportó así?" en tu equipo, activa la regla eqeqeq de ESLint en tu proyecto. Así eliminarás de una vez por todas las comparaciones laxas accidentales en toda tu base de código.

Hoja de ruta y herramienta interactivas

Sigue leyendo