The Strategy Tester in TradingView provides a comprehensive set of performance metrics after a backtest completes. Net profit, Sharpe ratio, maximum drawdown, profit factor. All of them. But these numbers disappear the moment you switch to live trading. Your strategy runs on the chart, and the Tester metrics are gone. You are trading blind, without the context that the backtest provided.
Table objects solve this problem. Pine Script tables render a grid of cells directly on the chart, anchored to a corner or centered. You can populate them with any data your code computes, updating on every bar to show live metrics as the strategy trades. A table can display your current equity, open position P&L, daily profit, win rate, or any other number your strategy tracks. It puts the dashboard where your eyes already are, on the chart itself.
How tables work in Pine Script
A table is created with table.new(), specifying the position and the number of columns and rows. The position is set with parameters like position.bottom_right or position.top_left, which anchor the table to a corner of the chart. You can also specify pixel offsets to fine-tune the placement.
Once created, you populate cells with table.cell(), specifying the column, row, and the text to display. Each cell can have its own background color, text color, text size, and text alignment. This gives you full control over the visual layout. You can create a clean, monospaced data display or a color-coded dashboard that highlights certain values.
The key capability is that table content updates on every bar. Unlike drawing objects, which persist until deleted, tables are regenerated on each script execution. This means you can display dynamic values that change as the strategy runs. Your current equity, open position P&L, trade count, win rate. All of these update in real time as the market moves.
One important constraint: tables do not have the same per-script limits as drawing objects. There is no 500-table cap. You can create one table and update its cells freely. The practical limit is how much data you can meaningfully display without cluttering the chart. A focused table with five or six key metrics is more useful than a dense grid with thirty numbers.
Building a live performance dashboard
The most common use case for tables is a live performance dashboard that shows the metrics you would otherwise only see in the Tester. When your strategy is running in live trading, you need to know your current equity, how many trades are open, what the daily P&L is, and whether you are ahead or behind. A table can display all of this in one place.
The implementation starts with creating the table once in the script's initialization, typically in an if bar_index == 0 block. Then, on every bar, you update the cell values with the current metrics. For a strategy, you access built-in variables like strategy.equity, strategy.opentrades, and strategy.closedtrades. For an indicator, you compute your own metrics and display those.
A practical dashboard might include these cells: current equity, open profit or loss, closed trade count, win rate, today's profit, and max drawdown so far. You organize these in a 2x3 grid, with the most important numbers in the top row. Color-coding the profit cells green when positive and red when negative adds immediate visual feedback that makes the dashboard useful at a glance.
Real-time signal strength indicators
Tables are not limited to strategy metrics. They can display any computed value, which makes them useful for indicators as well. A mean reversion indicator could display the current z-score of the price relative to its moving average. A momentum indicator could show the RSI value alongside a signal strength bar. The table becomes a heads-up display that supplements what the plots already show.
The advantage over plots is precision and labeling. A plot can show the RSI value, but a table can show the exact number with a label like "RSI: 67.3" in a fixed position. The user does not need to hover over the indicator line to read the value. It is visible in the corner of the chart at all times.
Combining tables with drawing objects creates a complete visual package. The drawing objects handle the visual representation on the price chart, while the table handles the numeric data that needs to be read precisely. An order block indicator could show the number of active blocks in a table, along with the most recent entry price and the invalidation level. This consolidates the indicator status into a single viewable area.
Displaying multi-timeframe data
Tables become especially useful when displaying data from multiple timeframes. If your indicator fetches the daily RSI while you are on a 15-minute chart, showing that daily value in a table makes it visible without needing to switch timeframes. The table cell can label the timeframe explicitly: "Daily RSI: 72" so there is no confusion about which period the number represents.
This pattern extends to any multi-timeframe indicator. A trend strength indicator that analyzes the 4-hour, daily, and weekly frames can display all three readings in a single row of the table, giving you a compact view of the trend across timeframes. The multi-timeframe guide covers the data fetching side; adding a table makes that data visible in a way that the plots alone cannot.
Tables versus labels
Labels and tables both display text on the chart, but they serve different purposes. Labels are positioned at specific bar and price coordinates, which means they move horizontally as the chart scrolls. Tables are anchored to a position on the screen, which means they stay in place regardless of scrolling or zooming. For metrics that should always be visible, tables are the correct choice.
Labels are better for annotating specific events: a buy signal at a particular bar, a price level that was touched, a note about a trade. Tables are better for continuous status information: current equity, open position count, live RSI value. Using the right tool for each job produces a cleaner chart. The drawing objects guide covers labels in detail and explains when to use each object type.
The practical value of on-chart metrics
The gap between backtest and live trading is partly a visibility gap. When you are in the Strategy Tester, the numbers are right there. When you go live, those numbers vanish unless you build a way to see them. Tables bridge that gap by bringing the metrics to the chart where you are actually trading.
Building a table dashboard is not complicated code, but it is easy to get wrong on the first try. Positioning, cell sizing, and color logic require a few iterations to feel natural. The value is immediate: you look at the chart and know exactly where you stand, without opening a separate panel or running a new backtest. For anyone trading with real capital, that visibility is worth the effort to implement correctly.
If you are building an indicator and want to add a dashboard, or if you have a strategy that needs live metrics visible on the chart, the table system in Pine Script provides the tools to do exactly that. The implementation is straightforward, and the visual improvement to your trading setup is immediate.
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.