Guide

Everything New in Pine Script v6, Ranked by What Matters

Pine Script v6 landed in November 2024 and has grown steadily since. Here is the honest ranking: which changes actually change how you write code, and which are nice-to-haves.

13 min read

TradingView released Pine Script v6 on November 13, 2024. It is the biggest update to the language since v4 introduced the modern syntax, and unlike a normal version bump it both unlocks new capabilities and changes how existing code behaves. Since launch, TradingView has kept adding features through 2025 and into 2026, including volume footprint requests in January 2026. This is the flagship guide to what changed, ordered by how much it actually affects your day-to-day work rather than the order TradingView announced things.

If you are moving existing scripts up from v5, pair this with our v5 to v6 migration guide, which focuses on the exact fixes. This article is about understanding the new landscape.

ChangeWhat it unlocksImpact
Dynamic requestsMulti-symbol scanners inside loopsHigh
Strict booleansFewer silent na bugs, some breaking changesHigh
Runtime loggingReal debugging with log.info / log.errorHigh
EnumsReadable state machines, type-safe inputsMedium
Unlimited backtestingTest across all available historyMedium
Dynamic for-loop boundsLoop ranges that vary at runtimeMedium
Bid/ask variablesAccess to spread dataSituational

Dynamic requests: the headline capability

The single most consequential change is that request.security and the other request functions now accept series arguments for the symbol and timeframe. In v5, the symbol you requested had to be effectively fixed, which meant you could not loop over a watchlist and request each ticker in turn. In v6 you can, so a whole class of tools that were simply impossible before, multi-symbol scanners, sector-rotation dashboards, breadth indicators, are now on the table.

pine
//@version=6
indicator("Dynamic request sketch")

symbols = array.from("AAPL", "MSFT", "GOOG", "AMZN")

var float[] closes = array.new_float()
if barstate.islast
    array.clear(closes)
    for i = 0 to array.size(symbols) - 1
        sym = array.get(symbols, i)
        c = request.security(sym, timeframe.period, close)
        array.push(closes, c)

plot(array.size(closes) > 0 ? array.get(closes, 0) : na)

This power comes with a memory cost, and that is where the RE10139 error comes from when you request too many symbols at once. We cover the scanner pattern and those limits in detail in dynamic requests in Pine Script v6.

Strict booleans: the change most likely to break your code

In v5, a boolean value could quietly be na, and the language tolerated it. In v6, booleans in conditional contexts are expected to be genuinely true or false. This catches a real category of bugs, where an undefined value slipped through a condition and behaved unpredictably, but it also means v5 code that relied on the loose behavior can now fail to compile or behave differently. The fix is to make booleans explicit, guarding values that might be na before using them.

pine
//@version=6
indicator("Strict boolean handling")

// A value that could be na early on the chart
maSlopeUp = ta.sma(close, 200) > ta.sma(close, 200)[1]

// Guard it so the boolean is always real
ready = bar_index > 200
signal = ready and maSlopeUp

bgcolor(signal ? color.new(color.green, 90) : na)

This is also the most common reason pasted v5 code, or code from a generic AI trained on older examples, refuses to compile in a v6 editor. Our type system guide explains the stricter rules, and the compile-errors guide covers the fixes.

Runtime logging: real debugging at last

Before v6, debugging Pine Script meant plotting a value and reading it off the chart, or abusing labels. v6 added a proper logging system: log.info, log.warning, and log.error send timestamped, structured messages to a dedicated Pine Logs pane. You can log conditionally, inspect values at the exact bar they occurred, and trace why a branch did or did not fire. This is a genuine quality-of-life leap, and we walk through the workflow in runtime logging in Pine Script.

PineScripter targets v6 syntax by default and updates older scripts to match

Enums: readable state, type-safe inputs

v6 introduced enums, named sets of constant values. Before, you tracked state with magic strings or integers that were easy to typo and impossible for the compiler to check. Enums make a state machine read like plain English and give you dropdown inputs that cannot hold an invalid value. They are a medium-impact change because they do not unlock anything new, but they make the code you already write cleaner and safer. See enums in Pine Script v6 for the patterns.

Unlimited backtesting and dynamic loop bounds

v6 lifted the historical limit on how many bars a strategy could backtest across, so on supported plans you can test over all the history available for a symbol rather than a capped window. That matters for getting a statistically meaningful number of trades, a point we make in how TradingView backtesting actually works. Separately, for loops can now take bounds that are determined at runtime, which pairs naturally with dynamic requests when the number of things to iterate over is not known in advance.

The rest, briefly

v6 also added access to bid and ask variables for spread-aware logic, new drawing and strategy refinements, and a steady stream of additions through 2025 and 2026, capped so far by volume footprint requests in January 2026 for traders who need order-flow style data. These are situational: powerful if your strategy needs them, invisible if it does not. The point of ranking is to keep them in perspective rather than treating every release-note bullet as equally important.

What v6 means in practice

If you write new scripts, start in v6 and lean on dynamic requests, logging, and enums. If you maintain v5 scripts, the strict-boolean change is the thing most likely to bite, so migrate deliberately rather than assuming a version bump is free. And if you use AI to generate Pine Script, be aware that most general models were trained on a web full of v4 and v5 code, so they lag the current language and will happily hand you outdated syntax that a v6 editor rejects.

That lag is exactly the gap a specialized tool closes. PineScripter targets v6 syntax by default, has the current manual as context, and validates against TradingView so you are not left translating errors from old code. If you want to try the new capabilities without first memorizing every change, describe what you want at PineScripter and iterate from working v6 code. For why generic models fall behind, see why ChatGPT fails at Pine Script.


Disclaimer: PineScripter is a coding tool for Pine Script development. It does not provide financial advice and does not guarantee trading profits. Always backtest strategies thoroughly and understand the risks before live trading.