Quick answer: The most common causes are: the script has a syntax error preventing it from compiling, the variable lacks a type hint so the editor cannot determine how to display it, or the scene needs to be closed and reopened for the Inspector to refresh after adding new exports.

Here is how to fix Godot exported variable not showing inspector. You added @export to a variable in your GDScript, saved the file, selected the node in the scene tree — and the variable is nowhere in the Inspector. No new property, no section, nothing. This is a deceptively common problem in Godot 4, and it usually has nothing to do with the export annotation itself. Let us work through every cause.

The Symptom

You have a script attached to a node with one or more @export variables declared. When you select that node in the scene tree, the Inspector shows the node’s built-in properties but none of your custom exported variables appear. There is no “Script Variables” section, or the section exists but is missing the variable you just added.

This can happen when you first attach a script to a node, when you add new exports to an existing script, or seemingly at random after the editor has been open for a while. The behavior is the same in all cases: the variable exists in the script but the Inspector does not display it.

A related variant is the export appearing in the Inspector but with the wrong control type. For example, you expect a slider but see a text field, or you expect a resource picker but see nothing. This points to a type hint issue rather than a visibility issue, but the root cause is similar.

Another variant is exported variables appearing for some nodes but not others that use the same script. This usually means the scene file has cached an older version of the script’s metadata, and a reload is needed.

Script Compilation Errors

The single most common cause is a syntax error somewhere in your script. When a GDScript file has a parse error, the engine cannot compile it, and the editor falls back to displaying the node without any script properties. The error may not be in the @export line itself — it could be anywhere in the file.

Godot shows compilation errors in the bottom panel (the “Errors” or “Output” tab), but these are easy to miss if you are focused on the Inspector. The script editor also marks errors with red indicators in the gutter, but if you edited the file externally, you may not see these until you switch to the Script tab.

Check for these common syntax issues that prevent compilation:

# ERROR: Missing type hint or default value (ambiguous type)
@export var speed  # No type, no default - editor doesn't know what to show

# CORRECT: Provide a type hint
@export var speed: float = 100.0

# CORRECT: Type inferred from default value
@export var speed = 100.0

# ERROR: Using Godot 3 syntax
export(float) var speed = 100.0  # Will not parse in Godot 4

# ERROR: Typo in annotation
@Export var speed: float = 100.0  # Case-sensitive - must be lowercase

If the script has any error, even on a line unrelated to the export, the entire script fails to compile and no exports will appear. Fix all errors first, then check the Inspector again.

A particularly sneaky issue is trailing whitespace or invisible characters in the file, especially if you copy-pasted code from a website. These can cause parse errors that are not visible in the editor. If you suspect this, try retyping the @export line manually rather than pasting it.

Type Hints and Supported Types

The @export annotation requires the editor to know what type of control to display in the Inspector. If the engine cannot determine the variable’s type, it may silently skip the export. Always provide an explicit type hint:

# Basic types
@export var health: int = 100
@export var speed: float = 200.0
@export var player_name: String = "Player"
@export var is_active: bool = true

# Engine types
@export var color: Color = Color.WHITE
@export var offset: Vector2 = Vector2.ZERO
@export var texture: Texture2D
@export var scene: PackedScene

# Range hints
@export_range(0, 100, 1) var percentage: int = 50
@export_range(0.0, 1.0, 0.01) var volume: float = 0.8

# Enum exports
@export_enum("Warrior", "Mage", "Rogue") var character_class: String

# Custom resources (requires class_name on the resource script)
@export var stats: PlayerStats  # PlayerStats must have class_name declared

For custom resource types, the class must have a class_name declaration at the top of its script. Without class_name, the type is not registered globally and the editor cannot resolve the type hint in the export annotation. This is a common gotcha when working with custom data classes.

Note that some types cannot be exported or have limitations. Arrays of custom types need specific syntax (@export var items: Array[MyType]), and dictionaries have limited export support. If you try to export an unsupported type, the variable may silently fail to appear.

The specialized export annotations like @export_range, @export_enum, @export_file, @export_dir, @export_multiline, @export_color_no_alpha, and @export_node_path each have their own syntax requirements. Using the wrong annotation for a type will cause either a compilation error or the export not appearing.

Scene Reload Requirements

Even after fixing all syntax and type issues, the Inspector may not update immediately. Godot caches script metadata when a scene is loaded, and adding or removing exports does not always trigger a refresh. You need to force the editor to re-read the script.

The most reliable way to refresh exports is to close the scene tab and reopen the scene file from the FileSystem dock. Simply saving the script is not always enough. You can also use Scene > Reload Saved Scene from the menu bar, which reloads the current scene without closing the tab.

If you are using an external editor (VS Code, Vim, etc.) to edit GDScript files, the Godot editor may not detect file changes automatically. In Project Settings, under Text Editor > External, make sure the “Auto reload scripts on external change” option is enabled. Without this, the editor continues using the last version it loaded from disk.

Another approach is to briefly detach and reattach the script to the node. Remove the script from the node in the Inspector, save the scene, then reassign the script. This forces the editor to re-parse the script and rebuild the Inspector panel from scratch. This is the nuclear option but it always works.

In rare cases, the .godot/ directory (which contains cached imports and metadata) can become stale. Closing Godot, deleting the .godot/ folder, and reopening the project forces a full rebuild of all cached data. This solves export display issues that persist after all other fixes.

Tool Scripts and Editor Interaction

If you need exported variables to do something in the editor (not just at runtime), your script needs the @tool annotation at the very top of the file. Without @tool, the script’s code only runs during gameplay, and any logic that depends on export values will not execute in the editor.

@tool
extends Sprite2D

@export var radius: float = 50.0:
  set(value):
    radius = value
    queue_redraw()  # Redraws in editor when value changes

func _draw():
  draw_circle(Vector2.ZERO, radius, Color.RED)

The @tool annotation must be the first line of the script, before extends. If it appears anywhere else, it has no effect. When using @tool, be careful with code in _ready() and _process() — that code will run in the editor, which can cause unexpected behavior or even crash the editor if it modifies the scene tree incorrectly.

Export variables with setters (as shown above) are particularly useful in tool scripts because they allow the editor to react immediately when a value is changed in the Inspector. The setter runs in the editor, letting you update visuals, validate ranges, or trigger redraws without running the game.

If you only need @tool behavior for certain parts of your script, use Engine.is_editor_hint() to guard editor-only code paths. This prevents gameplay logic from executing in the editor while still allowing export-related code to run.

"Ninety percent of the time, the export is not showing because the script does not compile. Check the Output panel first. The remaining ten percent is a scene reload issue."

Related Issues

If your exported variable shows up but resets to its default value every time you run the scene, see our guide on export variable resource null at runtime. For cyclic reference errors that prevent scripts with exports from loading, check GDScript cyclic dependency errors. If your exported node path returns null when you access it, get_node returning null in _ready covers the initialization order issues involved.

Close the scene tab and reopen it. The Inspector will refresh.