Roblox 'attempt to index nil': 6 Causes & Fixes

TL;DR

attempt to index nil with 'X' is Roblox's way of saying: "you tried to access a property or child on something that doesn't exist." There are exactly six root causes that cover ~95 % of every occurrence of this error. Fix the right cause and the error disappears — for good.

What the error actually means

This error appears whenever a Luau script tries to access a property or method of a variable that hasn't been initialized or doesn't exist. It occurs because Roblox uses Luau (a dialect of Lua) for scripting, and attempting to access properties on a nonexistent value always results in a nil indexing error.

Roblox error messages for nil indexing follow a consistent format: [ScriptPath]:[LineNumber]: attempt to index nil with '[PropertyName]'.

For example:

ServerScriptService.MyScript:17: attempt to index nil with 'Humanoid'

This indicates that at line 17, the script is trying to access the Humanoid property of a nil value. The variable that should hold the object is empty. Read the line number, then trace back through your code to where that variable was assigned — that is where the real problem lives.

Cause 1 — Accessing an object before it exists (timing issue)

This is the single most common cause. The most frequent cause of nil errors is attempting to access objects before they exist in the game hierarchy. When a script runs before an object has been parented to the workspace or replicated to clients, FindFirstChild() or direct references return nil. This is particularly problematic in server-client architectures where replication delays can cause temporary nil states.

Bad:

-- LocalScript runs immediately; Character may not be loaded yet
local character = game.Players.LocalPlayer.Character
local humanoid = character.Humanoid  -- nil if character isn't loaded!

Good:

local player = game.Players.LocalPlayer
local character = player.Character or player.CharacterAdded:Wait()
local humanoid = character:WaitForChild("Humanoid")

WaitForChild pauses the script until the object appears, preventing errors by making sure the object exists before accessing it. This function is mostly used when waiting for objects to load (especially when scripts run before everything is created) and ensuring network-replicated objects (like StarterGui elements) are available.

Rule of thumb: use WaitForChild in LocalScripts (client-side, where replication is not instant). In server Scripts where you created the object yourself, direct indexing is fine.

Cause 2 — Wrong parent / wrong service

Scripts constantly look for objects in the wrong container. A GUI stored in PlayerGui gets searched in StarterGui. A value stored in ServerStorage gets searched in ReplicatedStorage. The hierarchy path is wrong, so the search returns nil, and the next line explodes.

Example error pattern:

-- Module is in ServerScriptService, but the LocalScript looks in ReplicatedStorage
local MyModule = require(game.ReplicatedStorage.MyModule)  -- nil!
MyModule.DoSomething()  -- attempt to index nil with 'DoSomething'

Fix: Double-check where each object actually lives in the Explorer panel. ModuleScripts that need to be required by both the server and a LocalScript must sit in ReplicatedStorage (or a sub-folder of it). Server-only modules can live in ServerScriptService.

Cause 3 — Typo or case mismatch in the name

Luau is case-sensitive. humanoid, Humanoid, and HUMANOID are three completely different things. A single wrong capital letter produces a nil return from any name-based lookup.

-- "HumanoidRootPart" is the real name, not "humanoidRootPart"
local root = character:FindFirstChild("humanoidRootPart")  -- returns nil
local position = root.Position  -- boom: attempt to index nil with 'Position'

Fix: Always copy-paste instance names directly from the Explorer, or use autocomplete in Roblox Studio to avoid manual typing errors.

Cause 4 — FindFirstChild() returned nil and you didn't check

FindFirstChild() returns nil if an instance with the name specified is not found; WaitForChild() waits for an instance, yielding the current thread until it does — if it is not found in under 5 seconds then an 'infinite yield' error is thrown.

Many scripts call FindFirstChild() and then immediately access the result without any nil check, assuming the object always exists.

local invFolder = player:FindFirstChild("Inventory")
local coins = invFolder.Coins.Value  -- crashes if Inventory doesn't exist yet!

Fix: Always guard the result:

local invFolder = player:FindFirstChild("Inventory")
if invFolder then
    local coinsObj = invFolder:FindFirstChild("Coins")
    if coinsObj then
        print(coinsObj.Value)
    end
else
    warn("Inventory folder missing for", player.Name)
end

Or use the and short-circuit idiom for read-only access:

local value = invFolder and invFolder:FindFirstChild("Coins") and invFolder.Coins.Value

Cause 5 — ModuleScript not returning its table (or returning nil)

A very sneaky cause. Your ModuleScript runs without error, but if it doesn't explicitly return the module table at the bottom, require() hands back nil to whoever called it.

-- BAD: ModuleScript forgets to return
local MyModule = {}

function MyModule.Greet()
    print("Hello!")
end

-- Missing: return MyModule  ← THIS is required!

-- GOOD
local MyModule = {}

function MyModule.Greet()
    print("Hello!")
end

return MyModule  -- always end with this line

Also remember: when you try to retrieve a table from a client script, it can return nil in client scripts but not in server or module scripts. The server and client maintain separate instances of a ModuleScript. Mutating a module table on the server will not be visible to the client, so data that "exists" server-side shows up as nil on the client side.

Cause 6 — Character / Player object accessed from the server before it's ready

On the server, player.Character can be nil briefly right after a player joins or after respawning. Scripts that fire immediately on Players.PlayerAdded or handle a RemoteEvent can easily hit this window.

-- ServerScript — fires when player joins
game.Players.PlayerAdded:Connect(function(player)
    -- Character might not exist yet at this exact moment!
    local character = player.Character  -- could be nil
    local humanoid = character.Humanoid  -- attempt to index nil with 'Humanoid'
end)

Fix:

game.Players.PlayerAdded:Connect(function(player)
    -- Wait for the character to actually load
    local character = player.Character or player.CharacterAdded:Wait()
    local humanoid = character:WaitForChild("Humanoid")
    -- Now it's safe to proceed
end)

Quick-reference checklist

Defensive programming patterns worth keeping

Always wrap risky lookups:

local function safeGet(parent, name)
    local obj = parent:FindFirstChild(name)
    if not obj then
        warn(("[safeGet] Could not find '%s' inside '%s'"):format(name, parent:GetFullName()))
    end
    return obj
end

Use pcall for DataStore / external calls that might fail:

local success, result = pcall(function()
    return DataStoreService:GetDataStore("PlayerData"):GetAsync(player.UserId)
end)
if success and result then
    -- safe to use result
end

Enable Luau strict type checking at the top of your scripts during development:

--!strict

This makes Roblox Studio flag potential nil accesses before you even run the game.

FAQ

Q: My script worked yesterday and now throws this error — why? A: The most common reason is a hierarchy change. If you renamed, moved, or deleted an instance and a script still references the old path or name, it will get nil back. Check for any recent Explorer changes.

Q: WaitForChild freezes my game and prints "infinite yield". A: The object either doesn't exist at all or is in a different location. The infinite yield warning is printed after 5 seconds. Add a second timeout argument — e.g. WaitForChild("Part", 5) — so the script fails gracefully instead of hanging forever.

Q: I added a nil check but the error moved to a different line. A: Good — that means you correctly caught the first nil, but there's a second nil further down the chain. Apply the same check pattern at each step of a chained lookup.

Q: Should I always use WaitForChild instead of direct indexing? A: No. On the server, when you created the object yourself and you know it exists synchronously, direct indexing (workspace.MyPart) is perfectly fine and slightly faster. Reserve WaitForChild for situations where you are waiting on replication (typically inside LocalScripts, or when referencing objects created dynamically).

If you are still stuck after going through all six causes, paste your full script and the exact error line in the Roblox script development section — include the full stack trace from the Output panel. You can also browse ready-made, nil-safe scripts on GM Market to see well-structured examples in action.