◆ New — Strategy Validator, Code Fixer & Prop Compliance Checker are live. Try one free →
Home / Learn / Order Types Explained: Market, Limit, Stop, and Stop-Limit (and How Each Gets Filled)
Trading Education

Order Types Explained: Market, Limit, Stop, and Stop-Limit (and How Each Gets Filled)

A precise guide to the four core order types — market, limit, stop, and stop-limit — organised around the one distinction that actually matters: whether an order guarantees execution or guarantees price, because no order guarantees both. We map each type to its fill behaviour and to how Pine Script's Strategy Tester and MetaTrader simulate it, so your backtest assumptions match reality. Educational only, not financial advice; understanding order mechanics is about correctness, not returns.

What is the difference between market, limit, stop, and stop-limit orders?

The four order types differ along one axis: a market order guarantees execution but not price; a limit order guarantees price (or better) but not execution; a stop order becomes a market order once a trigger price is touched, so it guarantees execution once triggered but not price; and a stop-limit order becomes a limit order once triggered, guaranteeing price but not execution. Every order type is a choice about which guarantee you keep and which you surrender — no order gives you both a guaranteed price and a guaranteed fill.

That single trade-off explains everything else. A market order says 'fill me now, at whatever the best available price is'; you accept slippage in exchange for certainty of getting in or out. A limit order says 'fill me only at my price or better'; you accept the risk of never filling in exchange for price control. Stop orders exist to activate an order when the market reaches a level you're watching — the stop price is a trigger, not the fill price. What the order becomes after the trigger (a market order or a limit order) is what determines its fill guarantee.

Getting this right is not pedantry — it is the difference between a backtest that reflects what would have happened and one that quietly assumes fills you'd never have received. A stop-loss modelled as a limit order will 'protect' you in the tester at prices a real stop would have slipped straight through. This is educational only and not financial advice; the aim is correct mechanics, not a claim about profitability.

Market and limit orders: execution vs price

A market order executes immediately against the best available resting liquidity. In a deep, quiet market it fills at or very near the price you saw; in a thin or fast market it 'walks the book', taking progressively worse prices until it's filled, which is one concrete source of slippage. The guarantee is only that you will fill, and — importantly — a buy market order fills at the ask, a sell at the bid, so you cross the spread the moment you use one. That spread cost is real and is separate from slippage.

A limit order rests in the book at a price you specify and fills only when the market reaches it or better. A buy limit sits below the current price and fills at your price or lower; a sell limit sits above and fills at your price or higher. The catch is queue position and touch-versus-fill: price may reach your limit, fill part of your size, and move away, leaving the rest unfilled — or trade at your level without ever filling you because the resting orders ahead of you absorbed all the volume. 'The price hit my limit' does not guarantee 'my limit filled', and honest simulation has to respect that.

This is exactly where testers diverge from reality. TradingView's broker emulator and MetaTrader both assume a limit order fills if price trades through the level, ignoring queue position — a generous assumption that flatters limit-entry strategies. Market orders in the tester, meanwhile, often fill at the bar's open or close with no book-walking, understating slippage. Neither is 'wrong' as a modelling choice, but you must know which optimistic assumption you're inheriting before you trust the equity curve.

Stop and stop-limit orders: the trigger is not the fill

A stop order is dormant until price touches its trigger (the stop price); at that moment it converts into a market order and fills at whatever is then available. This is the mechanism behind a classic stop-loss: a sell stop resting below a long position triggers when price falls to it, then sells at market. Because the post-trigger order is a market order, the fill can be worse than the stop price — sometimes much worse on a gap or fast move. That negative slippage on stops is not a broker abuse; it is the definitional behaviour of the order type. A stop guarantees you get out (execution), not the price you get out at.

A stop-limit order adds a second price: when the stop trigger is touched, it places a limit order at the limit price rather than a market order. This caps the fill price — you'll never fill worse than your limit — but reintroduces the limit order's failure mode: if price blows straight through both the stop and the limit (a gap, a spike, a flash move), the limit doesn't fill and you are left with no execution at all. On a protective stop-loss this is genuinely dangerous: the exact fast-market scenario where you most need out is the one where a stop-limit can leave you holding the position.

So the choice is explicit. A plain stop prioritises getting the trade done and accepts price uncertainty; a stop-limit prioritises price control and accepts execution uncertainty. For risk exits, most traders want the execution guarantee of a plain stop precisely because an unfilled protective order in a fast market is the worst outcome. Knowing which one your code emits — and which one your tester assumes — is a correctness question, not a style preference.

How Pine Script and MQL model each order type

In Pine Script v6, strategy.entry() and strategy.order() default to market orders and can be given a limit and/or stop argument to become limit, stop, or stop-limit orders. Crucially, strategy.exit()'s stop= parameter models a stop order (fills at market once the level is touched, so the tester may fill it at the bar's price beyond your level), while limit= models a take-profit limit order. A minimal, validator-clean example makes the wiring explicit:

//@version=6
// Educational only — validate before trading; not financial advice.
strategy("Order type demo", overlay = true)

stopPts = input.int(300, "Stop (points)", minval = 1)
tpPts   = input.int(600, "Take-profit (points)", minval = 1)

longSig = ta.crossover(close, ta.sma(close, 20))
if longSig and barstate.isconfirmed and strategy.position_size == 0
    strategy.entry("Long", strategy.long)          // market entry

if strategy.position_size > 0
    strategy.exit("Exit", "Long",
         stop  = strategy.position_avg_price - stopPts * syminfo.mintick,  // stop order
         limit = strategy.position_avg_price + tpPts  * syminfo.mintick)   // limit order

The stop= level is a real price (built from strategy.position_avg_price and converted from points via syminfo.mintick), and it behaves as a stop: once the bar's low reaches it, the tester books the exit — but the honest reality is that a live stop can slip past this level. The limit= take-profit, by contrast, will only be credited in the tester when price trades through it, mirroring a limit order's price guarantee.

In MetaTrader, OrderSend (MQL4) and OrderSend/trade.PositionOpen with pending-order types (MQL5) expose the same four behaviours: OP_BUY/OP_SELL are market, OP_BUYLIMIT/OP_SELLLIMIT are limits, OP_BUYSTOP/OP_SELLSTOP are stops. A frequent bug is placing a stop or limit inside the broker's minimum stop-level distance, which returns error 130 (invalid stops). The correct pattern is to check MODE_STOPLEVEL/SYMBOL_TRADE_STOPS_LEVEL and normalise prices before sending — a correctness detail the tester won't warn you about.

Matching your assumptions to reality

The reason order-type precision matters for anyone testing a strategy is that each type carries a different fill assumption, and a backtest is only as honest as those assumptions. If your logic uses market entries, your realistic results depend on modelling spread and slippage — the tester's clean open-price fill is optimistic. If it uses limit entries, the tester's 'price touched, therefore filled' rule ignores that you might have sat unfilled at the back of the queue while price grazed your level and left. And if it uses stop exits, the tester fills you at your stop while a live fast market fills you beyond it.

The practical checklist is short. First, know which order type each entry and exit in your code actually emits — not what you intended, what the function produces. Second, for every market or stop order, add realistic slippage and cross-the-spread costs in the tester rather than leaving them at zero; a stop-heavy strategy tested with zero slippage is systematically flattered. Third, for every limit order, treat 'price reached the level' in the tester as an upper bound on how often you'd really have filled, and be sceptical of strategies whose edge depends on abundant limit fills at exact levels. Fourth, never model a protective stop as a limit — the whole point of the stop is the execution guarantee you'd lose.

Done honestly, order types are not a trivia topic; they are where a lot of the gap between backtest and live performance actually lives. A strategy that only works because the tester filled its stops at the exact stop price, or its limits every time price kissed the level, is fitting to an assumption, not an edge. This is educational only and not financial advice: understanding order mechanics improves the correctness of your testing, not the profitability of your trading, and every backtest remains a description of the past, not a forecast. Trading carries a real risk of loss.

Key takeaways

Educational only — not financial advice. Trading involves substantial risk of loss.

Catch the bug that compiles.Run auditGet Pro