How to Use Nullable Boolean in Kotlin if Expressions

By the end of this page, you will understand how Kotlin handles nullable Boolean values, why !! is usually unnecessary here, when smart casts work, why properties behave differently from local variables, and the most idiomatic ways to write conditions such as if (b == true) safely.

In Kotlin, Boolean? means a Boolean that can be:

• true
• false
• null

That is different from plain Boolean, which can only be true or false.

This matters because an if condition must evaluate to a non-null Boolean. Kotlin will not let you directly use a Boolean? where a Boolean is required, because null is a possible value.

A common beginner reaction is to use !!:

if (b != null && b!!) {
    ...
}

While this may work in some cases, !! is not the idiomatic solution. The !! operator means: “I am certain this value is not null, and if I am wrong, throw a NullPointerException.”

Think of Boolean? as a three-state switch instead of a normal two-state switch.

A normal Boolean is like a light switch with only two positions:

• ON (true)
• OFF (false)

A Boolean? adds a third position:

• ON (true)
• OFF (false)
• UNKNOWN (null)

An if statement only knows how to deal with ON or OFF. It cannot directly act on UNKNOWN.

So when you write:

if (b == true)

you are really saying:

• proceed only if the switch is definitely ON
• treat OFF and UNKNOWN the same for this condition

That is why this pattern feels natural in Kotlin.

The most useful ways to handle a nullable Boolean are shown below.

1. Check for explicit true

val b: Boolean? = getFlag()

if (b == true) {
    println("Flag is true")
} else {
    println("Flag is false or null")
}

This is the most idiomatic solution when you only want the true case.

2. Check for explicit false

if (b == false) {
    println("Flag is explicitly false")
}

This excludes null.

3. Handle all three states separately

when (b) {
    true -> println("True")
    false -> println("False")
    null -> println("Null")
}

Use this when null has its own meaning.

Consider this example:

val b: Boolean? = null

if (b == true) {
    println("Do something")
} else {
    println("Do something else")
}

Here is what happens step by step:

1. b is declared as Boolean?.
2. Its value is null.
3. Kotlin evaluates b == true.
4. Since b is null, the comparison result is false.
5. The if block is skipped.
6. The else block runs.

Now with b = false:

val b: Boolean? = false

Execution:

1. b == true is evaluated.

Nullable Booleans show up in many real programs.

API responses

An API might send a field that is missing or unknown:

data class UserSettings(
    val emailVerified: Boolean?
)

if (settings.emailVerified == true) {
    showVerifiedBadge()
}

Database values

A database column may allow nulls:

if (row.isArchived == false) {
    displayRecord()
}

Feature flags

A feature flag might not be initialized yet:

if (featureFlag == true) {
    enableNewCheckout()
}

Form state

A checkbox value may be unset until the user interacts:

if (form.acceptedTerms == true) {
    submitForm()
}

Configuration values

Optional config may default to off when missing:

val debugMode: ? = config[]
 (debugMode == ) {
    println()
}

In real Kotlin codebases, developers usually avoid !! unless they have no better option.

Common pattern: explicit true check

if (user.isAdmin == true) {
    showAdminPanel()
}

This is clear and compact.

Guard clause pattern

if (request.isAuthorized != true) return
processRequest()

This is common in service methods and controllers.

Snapshot a property into a local variable

val active = session.isActive
if (active == true) {
    startTracking()
}

Developers do this when smart casting is not available for a property.

Handle three states explicitly with when

when (task.completed) {
    true -> markGreen()
    false -> markRed()
    null -> markGray()
}

This is useful when null has business meaning.

Defaulting with the Elvis operator

1. Using !! unnecessarily

Broken or risky code:

if (b!!) {
    doSomething()
}

Why it is a problem:

• crashes if b is null
• hides the fact that null is possible

Safer version:

if (b == true) {
    doSomething()
}

2. Forgetting that Boolean? is not Boolean

Broken code:

val b: Boolean? = getFlag()
if (b) {
    doSomething()
}

Why it fails:

• if requires a non-null Boolean
• b might be null

Fix:

val b: Boolean? = ...

Common safe checks:

if (b == true) { ... }      // only true
if (b == false) { ... }     // only false
if (b != true) { ... }      // false or null
if (b != false) { ... }     // true or null

Convert to non-null Boolean:

val value = b ?: false
if (value) { ... }

Handle all three states:

when (b) {
    true -> ...
    false -> ...
    null -> ...
}

Smart cast notes:

• Local val variables often smart cast after b != null
• Properties may not smart cast
• Mutable properties are especially restricted
• Copy a property to a local variable if needed

Avoid when possible:

How do I check a nullable Boolean in Kotlin?

Use:

if (b == true) { ... }

This is the most common idiomatic approach.

Is b!! safe in an if condition?

No. It will crash if b is null. Use b == true unless you have a very specific reason not to.

Why does if (b != null && b) work for local variables but not always for properties?

Kotlin can smart cast local variables more easily because they are stable. Properties may change between checks or use custom getters, so Kotlin is more cautious.

What is the best way to handle a nullable property Boolean?

Usually either:

if (property == true)

or copy it first:

val value = property
if (value != null && value) { ... }

What if null has a different meaning from ?

• Null safety in Kotlin — nullable types and safe handling are the foundation of this topic.
• Smart casts — explains why Kotlin can sometimes treat a nullable value as non-null after checks.
• Safe call operator ?. — another core null-safety tool in Kotlin.
• Elvis operator ?: — useful for turning nullable values into non-null defaults.
• when expressions — helpful when true, false, and null all need separate handling.
• Properties vs local variables — important for understanding why smart casts behave differently.
• Mutable vs immutable variables — affects whether Kotlin can guarantee a value stays unchanged.
• Non-null assertion operator !! — directly related because it is the unsafe alternative discussed here.