Pine Script strategy() vs indicator() — Full Comparison Guide

What strategy() and indicator() actually mean in Pine Script

The simplest answer is this: use indicator() when the script’s main job is to calculate values, draw visuals, and emit alerts; use strategy() when the script’s job is to simulate trades and interact with the Strategy Tester.

TradingView’s declaration-statements documentation says every Pine script begins by declaring its type at compile time, and it also makes the difference explicit: indicators cannot use strategy.* built-ins or simulate trades, while strategies can define order sizing, capital assumptions, trading costs, and other simulation properties.

That is why the choice is not cosmetic. It changes what the script is allowed to do, how the chart tools behave, and what kind of confidence you can reasonably take from the output.

• indicator() is for calculations, visuals, alerts, and Pine Logs.
• strategy() is for trade simulation, order commands, and Strategy Tester output.
• The declaration statement changes both capability and runtime expectations.
• A strategy is not automatically “better”; it is simply for a different job.

When indicator() is the right choice

Indicator scripts are usually the best starting point when you are still defining the setup, tuning the signal logic, or trying to create chart clarity. They are ideal for overlays, oscillators, bias tools, dashboards, and alert conditions that traders want to inspect visually before pretending the idea is ready for simulation.

Indicators also behave differently in realtime. TradingView’s execution-model docs explain that indicators execute repeatedly on the open realtime bar as new updates arrive, while strategies behave differently by default. That matters because many alert bugs come from developers assuming the live indicator behaves like a closed-bar backtest.

If your current goal is to understand signal quality, clean the visuals, and make alerts trustworthy, starting with indicator() is usually the cleaner move.

• Choose indicator() for discretionary decision support and live chart interpretation.
• Use it when you need custom visuals, dashboards, or signal layers.
• Use it when you are still defining entries and exits honestly.
• Add alerts only after the signal logic is stable and understood.

When strategy() is the right choice

Strategy scripts are right when the trading rules are explicit enough to simulate. Once entries, exits, sizing assumptions, and costs are defined, strategy() lets you use order-placement commands and see the result in the Strategy Tester instead of relying on visual guesswork.

TradingView’s strategies documentation makes another point that traders often miss: strategy output is a simulation mediated by the broker emulator. It is useful, but it is still a model. No strategy result can guarantee future performance, and no clean equity curve excuses weak assumptions about slippage, execution timing, or overfitting.

So the correct use of strategy() is not to create fantasy certainty. It is to test rule consistency more honestly than an indicator alone can.

• Choose strategy() when entries, exits, and risk rules are specific enough to simulate.
• Use realistic assumptions for sizing, costs, and fills instead of flattering defaults.
• Treat the Strategy Tester as evidence, not proof.
• Keep indicator-style clarity in mind even inside strategies so the logic stays debuggable.

The execution difference most traders overlook

Execution behaviour is the part that confuses people most. TradingView’s execution-model page explains that indicators execute on every realtime update, but strategies execute only once per bar at the closing tick by default. If the strategy declaration includes calc_on_every_tick = true, the strategy can recalculate on each realtime update more like an indicator.

That single difference creates a lot of confusion. A signal that looks stable inside an indicator may not behave the same way when recreated inside a strategy, and a strategy alert will not necessarily fire with the same timing traders expected from the visual indicator unless the execution behaviour is understood properly.

This is why I tell traders to think beyond the code keyword. The real question is: what behaviour do you need right now, and which script type gives you the right evidence for that stage of the project?

• Indicators recalculate on realtime updates by default.
• Strategies close-bar recalculate by default unless you change the behaviour.
• Alert timing and visual timing can diverge if you do not account for runtime differences.
• Understanding rollback and confirmation is part of writing honest Pine Script.

How to choose the right script type for a real project

If the setup is still fuzzy, start with indicator(). If the rules are explicit and you want simulation evidence, move to strategy(). If the project will eventually drive alerts into automation, keep the Pine Script design conservative and explicit so the transition to live routing does not expose hidden ambiguity.

In practice, many strong workflows use both. The indicator clarifies the logic and live signal behaviour. The strategy tests the rule set. The bridge or broker layer, if one exists, then handles execution. Those are different layers, and separating them often produces much better systems.

• Use indicator() first when chart clarity and signal quality are still the priority.
• Use strategy() when the rules are explicit enough to simulate credibly.
• Do not confuse a strategy report with a live execution guarantee.
• If automation is the end goal, design alerts and execution assumptions deliberately from the start.

---

Frequently asked questions