Pine Script is one of the fastest ways in the world to turn a trading idea into something you can see on a chart. It is also a deliberately constrained language that will refuse to do entire categories of things, by design. Most frustration with Pine Script comes from not knowing which side of that line a given goal falls on. This article draws the line clearly.
The short version is in the table. The rest of the article explains why each limit exists, because the reasons are the same ones that make Pine Script fast, safe, and approachable in the first place.
| Pine Script can | Pine Script cannot |
|---|---|
| Compute indicators and strategies on chart data | Make outbound HTTP or API calls |
| Request other symbols and timeframes | Read or write files |
| Draw lines, labels, boxes, tables | Store data between sessions |
| Backtest and forward-test strategies | Place broker orders directly |
| Fire alerts to webhooks | Run true parallel threads |
| Scan a watchlist (v6 dynamic requests) | Access the full market at once |
What Pine Script is genuinely great at
Pine Script is chart-native. Your code runs against the exact data on your chart, plots appear directly on it, and there is zero setup: no environment, no data pipeline, no packages to install. You write an indicator and see it instantly. It has a deep library of built-in technical functions, a capable strategy engine with a built-in backtester, and an alert system that can reach the outside world. For the huge space of "compute something from price and volume and show it on the chart," nothing else is this quick.
The execution limits
Pine Script runs in a sandbox with hard performance ceilings, because TradingView runs millions of these scripts on shared infrastructure. Any loop on a single bar must finish within 500 milliseconds or the script errors out. Because your script runs once per bar, an expensive loop multiplies across thousands of bars, so this ceiling is easier to hit than it sounds. There is also max_bars_back, which limits how far back the script can reference a series and sometimes needs to be set explicitly.
Drawing objects are capped too. A script can only keep a limited number of lines, labels, and boxes at once, and older ones are removed as new ones are added past your configured maximum. On top of that, no drawing can be placed more than 9,999 bars into the past or more than 500 bars into the future relative to the current bar. Scripts that try to annotate every bar of a long history run into these caps quickly. When scripts get slow or hit limits, the fixes are in why your Pine Script is slow.
The connectivity limits
This is the wall people hit hardest. Pine Script cannot make outbound network calls. It cannot fetch a REST API, hit a data provider, or call a large language model. It cannot read or write files, and it cannot store data between sessions; each run starts fresh from chart data. It also cannot place orders with a broker directly from the script.
There is one bridge to the outside world, and it is important: alerts. A script can fire an alert, and that alert can hit a webhook URL with a JSON payload, which an external service you control can turn into broker orders. That is the only outbound path, and it is one-way. We map exactly what is and is not possible through it in can Pine Script connect to an API, broker, or webhook.
The language limits
Pine Script has no true parallelism; the once-per-bar model is inherently sequential. It has no general-purpose I/O, no ability to import arbitrary third-party libraries (only Pine Script libraries published on TradingView, covered in writing reusable libraries), and a focused standard library aimed at charting and technical analysis rather than general computing. You will not do machine learning training, heavy data science, or arbitrary math at scale inside Pine Script. Those are jobs for a general language, which is the honest tradeoff we lay out in Pine Script vs Python.
Why the limits exist
None of this is an oversight. The sandbox, the no-network rule, and the determinism are what let TradingView run everyone's scripts safely and reproducibly at massive scale. A script that cannot call the network cannot leak your data or hang on a slow server. A language that is deterministic gives the same result every time it replays the same bars. These constraints are the price of the speed and safety, and they are also the reason TradingView built its own language rather than embedding Python, which we explore in why TradingView built its own language.
How to decide if Pine Script fits your goal
Ask what your idea needs. If it needs to compute signals from price and volume, visualize them, backtest a strategy, and alert you or a webhook when conditions are met, Pine Script is an excellent fit and will get you there faster than anything else. If it needs external data, machine learning, tick-level simulation, or direct automated execution against a broker, you either need a general language or a hybrid where Pine handles the chart logic and an external service handles execution.
For the large majority of retail ideas, the goal lands squarely in Pine Script's sweet spot, and the only real friction is the syntax and the debugging cycle. That friction is what PineScripter removes: describe the idea in plain English, get working v6 code that respects these limits, and iterate on the chart. If your idea fits the map above, you can try it free at PineScripter. If it does not, this article just saved you weeks of fighting the wrong tool.
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.