Guide

TradingView backtest accuracy

Last reviewed: 15 September 2026·Tradelyze

TradingView backtest accuracy is how closely the Strategy Tester's simulated trades match the fills you could actually have gotten. The Strategy Tester replays your Pine Script rules faithfully on chart bars, but by default it guesses how price moved inside each bar. Comparing a second backtest's trades with yours, one by one, shows where those guesses change the result.

New to this? Start with exporting TradingView trades and price data.

What do Match Rate, Matched, TV Only and BT Only mean?

Match Rate is the share of trades that Tradelyze's re-run and your TradingView export agree on. The re-run is Tradelyze backtesting your Pine Script a second time, on the price file you uploaded. Match Rate is the large percentage on the Conversion Result card. A higher figure means the two backtests are more likely to be testing the same strategy.

Tradelyze counts two trades as a match when both go the same direction and their entry times are within five minutes of each other. TradingView times are read on the chart timezone you chose. Trades from before the other side's first trade are set aside as warmup, the stretch where indicators were still collecting bars. TradingView trades that entered after your price file ends are left out, because the re-run had no bars for them.

TV Trades includes trades that Match Rate sets aside, so Matched plus TV Only does not always add up to TV Trades. At a 100% match the card drops the counts and shows the line "Every backtest trade matched TradingView".

In that constructed example, 93.7% shows green. Yet 8 TradingView trades never happened in the re-run, and 4 re-run trades inside the window have no TradingView partner. Open Review comparison, or the Trade Details table on the Conversion Result card. Look for a pattern in those trades: the same session hour, the same exit type, or the start of the file.

What match rate is good enough?

No published standard says what match rate is good enough. Tradelyze's colors for Match Rate are a display choice: green at 90% or more, amber at 80% or more, and red when lower.

The colors are separate from the decision to halt a run, which uses the required match stated on the Optimization stopped card. They are also separate from Tradelyze's below-target email, which any match under 100% can trigger. The number of trades matters as much as the color. A green 90% of 40 trades leaves 4 unexplained trades, while 90% of 2,000 trades leaves 200.

What the unmatched trades were matters most. Suppose the TV Only trades include the biggest winners or the worst losing days. The re-run's profit and drawdown can then differ sharply from TradingView's, even with a green figure.

Why don't my trades match TradingView?

Trades usually fail to match TradingView because of a setting or the data, not because either backtest is broken. Check these causes roughly in the order they are quickest to rule out:

1. Chart timezone. Tradelyze's upload form asks for "The zone shown in your TradingView chart's bottom-right corner", because both uploaded files are stamped in that zone. In one internal Tradelyze test, a 1,275-trade export measured 100.00% on its chart timezone (India Standard Time) and 16.24% read as UTC. The backtest had reproduced it trade for trade; only the clock differed. That was a single test, not a general accuracy rate. The separate Exchange Timezone field sets where trading days start for prop-firm rules. The export guide's timezone section shows which zone to choose.
2. Indicator warmup. Indicators need a run of bars before they give values; a 200-bar moving average has nothing to say on bar 50. If your price file starts at a different point from TradingView's chart history, the two backtests start trading at different times. Tradelyze sets those early trades aside from Match Rate, and TV Comparable From marks where the comparison becomes fair.
3. Properties or Inputs changed only in TradingView. Tradelyze takes initial capital, commission, slippage, order size, pyramiding and input values from the script itself. They come from the strategy() header and the input() defaults. Did you change them in TradingView's Properties or Inputs tab? Then the upload form tells you to "update the defaults in your script to match and upload it again." TradingView strategy properties explains what commission, slippage and pyramiding each change. The export guide explains why script defaults must match what you ran.
4. Price data for a different range or timeframe. The price file must be for the same instrument and timeframe as the chart you exported from. TradingView trades after the file's last bar are left out of Match Rate. If the two files cover separate dates, no trade can match.
5. Extra timeframe files for request.security(). When a script reads another timeframe, the upload form asks for a price file for that timeframe as well. Tradelyze has not yet confirmed that extra-timeframe data is applied correctly in every case. With a multi-timeframe script and a low match, check this early: compare trades around the higher timeframe's bar changes.
6. Fill settings. Bar Magnifier, process_orders_on_close and similar settings change which bar and price an order fills at. A setting that exists only in TradingView's Properties window is not in the script you upload.

Fill settings cause the most disagreement when a stop and a target both sit inside one bar. A chart bar records only four prices, its open, high, low and close. Those four prices cannot show which level price reached first.

After fixing a cause, submit the strategy again so Baseline Matching measures the corrected setup. What to fix first when trades do not match walks through a timezone example step by step.

Why does Tradelyze re-run my backtest before optimizing?

Tradelyze re-runs your backtest first because every later result is useful only if it tests the strategy you tested on TradingView. Backtest trade matching is how that is checked: the re-run's trades are compared with your TradingView export, trade by trade. The first stage of every run is Baseline Matching, which the app describes as "Checking the converted strategy against your TradingView trades".

At Baseline Matching, Tradelyze backtests your Pine Script once on the price file you uploaded. It uses the script's own strategy() and input() defaults. The backtest runs on Tradelyze's own Pine Script backtester, and no AI rewrites your script. The app still calls this re-run the "converted strategy". Its trade list is lined up against the trade list you exported from TradingView's Strategy Tester. The guide to exporting TradingView trades and price data covers both files.

If the match is lower than the figure Tradelyze requires, the run stops before optimizing anything. An amber card titled Optimization stopped shows the measured match and three counts: Matched, Backtest trades and TradingView trades. It also names the clock the trades were compared on. The explanation on that card normally states the percentage required. Two buttons follow: Continue anyway and Review comparison.

What happens if I click Continue anyway?

Continue anyway lets a run that stopped at Baseline Matching go on to optimize Tradelyze's re-run of your strategy as it is. The Optimization stopped card states the consequence: "Every number the run reports will describe that build, not the one your TradingView export came from."

Clicking Continue anyway opens the optimization dialog. The run you submit from it skips the match check and nothing else. Optimization, walk-forward analysis, robustness scoring and prop-firm evaluation then all run on the re-run build.

Continue anyway is reasonable once Review comparison shows the unmatched trades are explained and minor. An example is a handful of trades at the very start of the file while indicators warm up. It is a poor choice when the cause changes the trades themselves. Examples are a wrong chart timezone, Properties or Inputs changed only in TradingView, or a price file covering different dates. Fix those and submit again, because they change the trades the whole analysis is built on.

How does a low match change the rest of my results?

A low match means the rest of your Tradelyze results describe the re-run build. That build trades differently from the strategy in your TradingView report, and every later card inherits the difference:

• Best Metrics and Recommended Parameters are tuned on the re-run build. They are in-sample, meaning measured on the same prices they were tuned on. That makes them the most optimistic figures on the page; see why Tradelyze's best metrics are in-sample.
• Top Trials ranks settings of the re-run build, not of your TradingView version.
• The walk-forward badge (PASS, FAIL or NO VERDICT) tests the re-run build on unseen data; see what makes a walk-forward result pass or fail.
• The robustness score and verdict stress-test the re-run build's trades; see what ROBUST, ACCEPTABLE, MARGINAL and FRAGILE mean.
• Each prop firm's Qualifies or Not Feasible badge is scored on the re-run build's days; see what Qualifies means.

A concrete case: the TV Only trades include the days with the largest losses. A Qualifies badge can then describe a build that never took those losing days. The daily loss rule it passed is not the one your TradingView strategy would face. Fix the cause of the mismatch, submit again, and judge the results only once the match is explained. Low trade counts weaken every one of these checks too, as overfitting and sample size explains.

What does TV Comparable From mean?

TV Comparable From is the first timestamp from which Tradelyze's figures can be compared with TradingView's own figures for the same strategy. Before that time, both backtests are still filling their indicators' lookback bars. They will disagree for reasons that have nothing to do with the strategy.

Tradelyze shows TV Comparable From on the Best Metrics card and as a column in the Top Trials table. When you set a Tradelyze result beside your TradingView report, compare them from that timestamp onward, not from the first bar of the file.

Is TradingView backtesting accurate?

TradingView backtesting accurately simulates your Pine Script rules on the chart's bars. It is not a record of fills you could have gotten. The Strategy Tester uses a broker emulator, the part that plays the role of your broker. TradingView's Pine Script documentation on strategies says the emulator fills orders "using only the available chart data by default."

So "accurate" breaks into four separate questions:

• Are the fills realistic for how price moved inside each bar?
• Are the settings in the report the ones you meant to test?
• Does the script use only data it could have known at the time?
• Would a second, independent backtest of the same script on the same data take the same trades?

Trade matching answers only the last question. A low match is often the first sign that one of the other three has a problem.

TradingView's documentation also separates backtesting from live conditions. In forward testing, it says, trading costs, slippage and liquidity can meaningfully change performance. This matters for your money: a live account or a prop-firm challenge fee gets sized from the Strategy Tester's numbers. If a re-run cannot reproduce the trades, those numbers rest on details you may not have chosen on purpose.

How does TradingView's Strategy Tester decide when orders fill?

TradingView's Strategy Tester fills orders on historical bars by following a set of stated default assumptions. TradingView's Pine Script documentation on strategies sets them out:

• Orders wait for the bar to close. By default a strategy calculates once each bar closes. The earliest an order can then fill is the open of the next bar.
• The path inside a bar is assumed, not known. When a bar opens closer to its high, the emulator assumes open → high → low → close. When it opens closer to its low, it assumes open → low → high → close.
• Limit orders fill at their price or better. Once price reaches the limit level, the order fills there or at a better price. The backtest_fill_limits_assumption parameter can require price to move past the level first.
• Fills on the close are optional. With process_orders_on_close = true in the strategy() declaration, market orders fill on the close of the bar that created them. Without it, they fill at the next bar's open.

Strategies with tight stops and targets that often fit inside a single bar depend most on this assumption. They are also where two backtests of the same script most often disagree. A small difference in how a bar is read flips the trade's result.

process_orders_on_close matters for trade matching too. It moves fills for orders placed at a bar's close one bar earlier, from the next open to that same close. TradingView's documentation says the "Order execution delay" setting in the Properties tab overrides it. The "Limit order execution" setting overrides backtest_fill_limits_assumption in the same way. Changed only in Properties, either setting is missing from the script you upload. Entries can then shift by a bar and fall outside Tradelyze's five-minute matching window.

What does Bar Magnifier change, and who can use it?

Bar Magnifier is a TradingView setting that looks at smaller bars inside each chart bar to decide which price was hit first. Without it, the Strategy Tester follows the fixed rule in TradingView's Pine Script documentation: price reaches whichever of the high or low is nearer the open first. TradingView's Help Center article on bar magnifier backtesting mode says the setting makes results "more similar to what would happen during forward testing" over the same period.

Bar Magnifier is not on every TradingView plan. TradingView's Pine Script documentation limits this extra intrabar detail to Premium and Ultimate plan users. TradingView changes its plans from time to time, so confirm on TradingView's own pricing page.

The setting goes by two names. TradingView's Help Center calls it Bar Magnifier and says it is toggled in the strategy's Settings/Properties window. The Pine Script documentation calls it Bar detalization, with a "High" option in the Properties tab and at the top of the strategy report. A script can switch it on by default with use_bar_magnifier = true in its strategy() declaration.

Bar Magnifier has a ceiling on long histories. TradingView's Help Center says a strategy cannot request more than 200,000 lower-timeframe bars. The Pine Script documentation adds that bars without intrabar data fall back to the default assumed path. Worked example (constructed arithmetic, not measured data): on a 5-minute chart each bar holds ten 30-second bars. That allows about 200,000 ÷ 10 = 20,000 of the most recent chart bars to be magnified. With 40,000 bars loaded, roughly the older half still uses the assumed path.

Bar Magnifier matters most when a strategy's stop and target often sit inside the range of a single chart bar. A strategy whose stop and target are usually many bars apart rarely meets a bar where the order of the high and low decides the trade. Before paying for a plan to get Bar Magnifier, check how often one bar in your trade list touched both the stop and the target.

For trade matching, the practical point is where the setting lives. Tradelyze builds its run from the script's own strategy() and input() defaults, not from TradingView's Properties window. A setting you switched on only in that window, Bar Magnifier included, is not part of the file you upload. Tradelyze has not confirmed whether its re-run applies use_bar_magnifier = true from a script header, so treat trades on wide bars as the likeliest mismatches either way.

What is Deep Backtesting, and is there a trade limit?

Deep Backtesting is a TradingView Strategy Tester mode that tests a chosen date range on all the history TradingView holds for a symbol, not only the bars loaded on the chart. TradingView's Help Center article How Deep Backtesting works says it starts when you open a strategy and select a time range, marked by a pink icon. Clicking Reset to chart session stops it.

• Which plans. The same Help Center article lists Deep Backtesting for Premium and higher plans.
• How much data. That article gives a limit of "up to two million bars and one million trades." A second Help Center article says a period longer than 2 million bars runs on its most recent 2 million bars.
• How many trades are kept. TradingView's documentation on the trade limit says a regular test keeps individual data for only the latest 9,000 trades and trims older closed trades. Trimmed trades are missing from the report's trade list and from downloaded CSV files. Deep Backtesting keeps every trade.
• Where results show. Only in the Strategy Report tab, not on the chart, according to TradingView's Help Center.
• Different numbers. TradingView's Help Center notes that a regular report and Deep Backtesting can give different results for the same strategy.

For trade matching, a trimmed report means an exported trade list that can begin later than your price file. Tradelyze's re-run then takes trades before TradingView's first exported trade. Tradelyze leaves those early trades out of Match Rate, so they do not count against the match. They still appear in the BT Only count. The cleanest fix is to export a date range that covers the same period as the price data you upload. For a strategy with more than 9,000 trades, that usually means exporting from Deep Backtesting, the mode that keeps every trade.

Can repainting or request.security lookahead make a backtest look better than it is?

Yes: repainting is when a Pine Script calculates differently on historical bars than it would have in real time. The dangerous kind in a backtest is a future leak, such as request.security() with lookahead on and no one-bar offset, which TradingView's documentation says returns "data from the future on historical bars." Tradelyze does not check scripts for repainting, so a high Match Rate shows only that two backtests agree on the same historical bars. Pine Script repainting and look-ahead bias explains how to test your script and write a non-repainting request.

Stage 1 · step 3 of 18. Next in the learning path: How to read a Tradelyze report

Frequently asked questions about TradingView backtest accuracy

Sources

• TradingView, Pine Script documentation, Concepts / Strategies: sections Broker emulator, Adjusting historical bar detail (including the Bar detalization setting and the 200,000-bar lower-timeframe limit), Limit orders, process_orders_on_close, Slippage and unfilled limits, Backtesting and forward testing, and Trade limit. Retrieved 15 September 2026.
• TradingView, Pine Script documentation, Concepts / Repainting: sections Introduction, Future leak with request.security(), and Strategies. Retrieved 15 September 2026.
• TradingView Help Center, What is bar magnifier backtesting mode, including the chart-to-intrabar timeframe table and the 200,000-bar limit. Retrieved 15 September 2026.
• TradingView Help Center, What is Deep Backtesting. Retrieved 15 September 2026.
• TradingView Help Center, How Deep Backtesting works. Retrieved 15 September 2026.
• TradingView Help Center, How much data is available for Deep Backtesting. Retrieved 15 September 2026.
• Tradelyze implementation, reviewed 15 September 2026, trade matching: the Baseline Matching stage backtests the uploaded Pine Script once with the script's own strategy() and input() defaults; trades are paired when they share a direction and their entries fall within five minutes of each other on the chart timezone; Match Rate is matched trades divided by the larger of the two in-window trade counts, with each side's trades from before the other side's first trade set aside and TradingView trades after the price data ends left out.
• Tradelyze implementation, reviewed 15 September 2026, display, halt and email: the match figure is green at 90% or more, amber at 80% or more and red otherwise; a match under the required figure halts the run before optimization, with Continue anyway and Review comparison actions; when optimization does not start automatically, a match below 100% sends an email stating the match is "below your 100% target"; upload-form and card wording is quoted as shown in the app.
• Tradelyze testing record, reviewed 14 September 2026: a 1,275-trade TradingView export that the backtest reproduced trade for trade measured 100.00% on its chart timezone (India Standard Time) and 16.24% read as UTC. This is a single internal test, not a general accuracy rate.