nz() in Pine Script replaces an na value with a supplied replacement, or with zero by default for numeric inputs. An available value passes through unchanged, including zero. Use na(value) to test whether a value is unavailable; use nz(value, replacement) only when that replacement matches the intended calculation. Pine Script v6 booleans cannot be na, and nz() no longer accepts boolean arguments.
Part of the Pine Script guide and function reference. The examples use numeric values and Pine Script v6 behaviour as of 25 September 2026.[1][2]
na, nz() and fixnan() at a glance
Scroll horizontally to read every column.
| Expression | Meaning for numeric values |
|---|---|
na |
An unavailable or undefined value |
na(value) |
True when the value is unavailable; false when it is available |
nz(value) |
Keep an available value; replace a missing numeric value with zero |
nz(value, replacement) |
Keep an available value; otherwise use the supplied replacement |
fixnan(value) |
Carry the latest available value forward across missing observations |
These operations answer different questions. An availability test preserves the distinction between missing and observed data. A replacement or carry-forward rule changes the series used by later calculations.[1]
What is the nz() formula and return value?
nz(source, replacement) = replacement when source is na; otherwise source
For numeric nz(source), the omitted replacement is zero. An input of 12 returns 12, an input of zero returns zero, and a negative input remains negative. The function is a missing-value replacement, not a test for whether a number is positive or acceptable.
The source and replacement must fit a supported overload. This page covers numeric inputs; the reference also documents colour overloads. Pine Script v6 does not accept boolean arguments in na(), nz() or fixnan(), because boolean values are now always true or false.[1][2]
A replacement may itself be unavailable. In that case, nz(source, replacement) can still return na. Naming a fallback does not make its data exist. Likewise, nz(value) does not check whether the resulting zero makes sense for a stop price, denominator or position size.
Worked example: replacement versus carrying a value forward
Illustrative sequence, not market data. Four consecutive observations are na, 12, na, 18. The custom replacement is 5, chosen only to make the differences visible.[1]
| Operation | Four outputs, in order | Meaning at the third observation |
|---|---|---|
| Keep the original series | na, 12, na, 18 | Still missing |
nz(source) |
0, 12, 0, 18 | Replaced with zero |
nz(source, 5) |
5, 12, 5, 18 | Replaced with the explicit fallback |
fixnan(source) |
na, 12, 12, 18 | The earlier 12 is carried forward |
fixnan() cannot fill the first missing observation here because no earlier available value exists. At the third observation, it can carry forward 12. That output means “last available value”, not “a fresh observation equal to 12”.
TradingView's techniques FAQ uses explicit replacements such as nz(src, historicMin) while updating historical extremes.[3] The fallback has a purpose in that algorithm; it is not a general instruction to replace all missing prices.
Why do the first bars sometimes contain na?
A history reference needs an earlier observation. On the first bar available to a script, close[1] has no preceding bar in the dataset, so it is unavailable. A rolling calculation can also need sufficient source history before returning a value; the requirement depends on the function.[1][4]
Missing data is not limited to startup. Some calculations deliberately return na between events. A conditional expression may use it to represent “no value on this bar”. Replacing every gap can remove that intended distinction.
When declaring an initially missing numeric variable, provide its type, such as float level = na. An untyped declaration using only na does not establish the value's type. For an availability test, use na(level) rather than comparing level directly with na.[1]
How can replacing na create a false price change?
Illustrative first-bar value: the current close is 100, and there is no previous close. The observed change, close - close[1], is unavailable. Replacing the previous close with zero instead produces 100 − 0 = 100, a change from a value that was never observed.
Replacing it with the current close produces 100 − 100 = 0. That defines a startup baseline, not an observed zero change. Whether to keep the gap or initialise a baseline belongs in the calculation's specification.
Illustrative sketch; not compiled or tested. Paste into TradingView's Pine Editor. The two outputs make that policy difference explicit; no alert or order is created.[1]
//@version=6
indicator("Missing previous value")
previous = close[1]
hasPrevious = not na(previous)
observedChange = hasPrevious ? close - previous : na
seededChange = close - nz(previous, close)
plot(observedChange, "Observed change")
plot(seededChange, "Change with startup baseline")
On later bars with an available previous close, both expressions use that observation. If the next close is 103 after 100, both give 103 − 100 = 3. The difference is how the calculation handles missing history.
How do missing values affect conditions and alert messages?
Unavailable numeric operands can propagate through arithmetic. A missing value does not become a known number because the surrounding expression is longer. In v6, boolean conditions have only two states, so record numeric availability explicitly when it matters.[1][2]
For example, a condition on nz(rank) can treat missing rank data as an observed zero. A condition on an explicitly checked, available rank preserves the difference. See ta.percentrank() and comparison samples.
Check the inputs before converting numbers into message text. TradingView's alert() accepts strings assembled at runtime, but string conversion cannot supply a missing observation.[5] The alertcondition() vs alert() comparison explains the message routes.
For PineConnector instructions, availability is only one check. The syntax reference requires the intended command, exact broker symbol and correctly specified parameters, with explicit units such as lots or pips.[6] Zero-filling a missing calculation does not validate those choices.
A valid numeric input precedes the condition, alert trigger, webhook delivery, PineConnector processing and EA order request. Broker acceptance, the deal and the position are separate outcomes. Follow the demo verification procedure to compare the actual message with the broker result.[7]
What mistakes should the missing-data rule prevent?
-
Missing confused with zero: zero can be a real observation.
na()distinguishes the two. -
Stale confused with current:
fixnan()can produce an available number that was observed on an earlier bar. - Substitution without valid units: a numeric fallback can be inappropriate for the field receiving it.
- A clamp hiding the substitution: zero can become a lower bound and appear plausible; see clamping numeric inputs.
- Old boolean code in v6: remove assumptions that a boolean can have a third, missing state. Changing only the version annotation does not resolve that logic.[2]
- Reusing an old alert: changing a fallback in the chart script does not update the saved alert. Recreate the affected alert after the change.[5]
Frequently asked questions
What does nz() do in Pine Script?
nz() keeps an available input unchanged and replaces an na input with a fallback. For numeric nz(source), the default fallback is zero. With nz(source, replacement), the supplied value is used instead. An actual zero is already available, so nz does not replace it with a different fallback.
What is the difference between na() and nz()?
na(value) tests whether a supported value is unavailable and returns a boolean answer. nz(value, replacement) returns a value, substituting the replacement when needed. Testing availability preserves the missing-data distinction; substitution changes the series used downstream. A replacement can itself be unavailable, so nz does not always produce an available result.
How is fixnan() different from nz()?
fixnan() replaces a missing observation with the most recent available value from the series. nz() uses zero for an omitted numeric fallback, or the explicitly supplied replacement. Carrying a previous value forward does not create a fresh observation, and fixnan cannot fill an initial gap before any available value exists.
Can nz() take a boolean in Pine Script v6?
No. Pine Script v6 booleans are always true or false and cannot hold na. The v6 migration guide removes boolean support from na(), nz() and fixnan(). When migrating older logic, distinguish unavailable numeric inputs from a false condition instead of trying to repair a boolean with nz.
Reviewed 25 September 2026. Facts were checked against the linked sources on that date. Nothing in this article was tested on a trading account and no code was compiled.
Related reading
- Pine Script guide and function reference
- alertcondition() vs alert()
- ta.percentrank() and relative rank
- Clamping with min and max
Sources
- TradingView – Pine Script v6 Reference Manual: na, nz and fixnan, accessed 25 September 2026.
- TradingView – To Pine Script version 6, accessed 25 September 2026.
- TradingView – Pine Script FAQ: Techniques, accessed 25 September 2026.
- TradingView – Execution model, accessed 25 September 2026.
- TradingView – Alerts, accessed 25 September 2026.
- PineConnector – PineConnector Syntax, accessed 25 September 2026.
- PineConnector – Test your setup, accessed 25 September 2026.
PineConnector executes the instructions you send it. It does not select trades, manage money, or hold funds. Trading carries risk, and past performance of any strategy does not indicate future results.
