n8n Sort and Limit nodes: order and cap your items (complete guide)

Sorting a list and keeping only part of it are such mundane operations that they get overlooked — until a "top 10 leads" report surfaces the worst ones, or a test workflow pushes 4,000 items into a pay-per-call API. n8n ships two dedicated nodes for this, Sort (n8n-nodes-base.sort) and Limit (n8n-nodes-base.limit), which take thirty seconds to configure and pair naturally. This guide walks through their actual parameters, the Sort + Limit pattern, and the typing traps behind most "weird" sort results.

Two nodes, one playground: the item list

Like Filter, Split Out and Aggregate or Merge, Sort and Limit belong to the transformation family: they talk to no external service, they reshape the array of items flowing between two nodes.

• Sort keeps every item but changes their order;
• Limit keeps the order but reduces the number of items.

Both operate on the whole batch at once, unlike Filter which evaluates each item in isolation. That matters: a Sort node placed inside a Loop Over Items loop would only sort the current batch, not the full dataset.

The Sort node and its three types

The node's main parameter is called Type and offers three modes: Simple, Random and Code.

Simple: fields and order

This is the default. You add one or more criteria through the Add Field To Sort By button, each made of:

• Field Name: the field to compare (score, created_at, customer.name in dot notation);
• Order: Ascending or Descending.

Multi-field sorting follows the declaration order: the first criterion decides, the second breaks ties, and so on. To rank orders by customer then by descending amount, declare customer as Ascending, then amount as Descending.

One option is worth knowing: Disable Dot Notation. While it is off, customer.name is read as "the name property of the customer object". If your data contains a field whose name literally includes a dot, turn it on so n8n stops splitting the string.

Random: the sampling type

The Random type shuffles items with no further parameter. Combined with a Limit, it yields a sample: three rows drawn from a 4,000-line file to validate an AI prompt, ten contacts from a database to test a send. It is the reflex to have before running an expensive workflow across an entire dataset.

One caveat: the draw is not reproducible between runs, and it assumes every item is already loaded in memory. The sampling literature addresses exactly this case: in "Random Sampling with a Reservoir", published in 1985 in ACM Transactions on Mathematical Software, Jeffrey S. Vitter describes algorithms that draw a uniform sample in a single pass and in constant space, without knowing the population size in advance (see on Google Scholar). That is the exact opposite of n8n's Random type, which requires everything to be fetched before choosing — hence the value of sampling at the source (a SQL LIMIT clause, an API parameter) once volumes get serious.

Code: a custom comparison function

The Code type expects a JavaScript comparison function with the same signature as the native Array.sort() comparator: two items a and b, and a return value that is negative if a should come before b, positive for the opposite, zero if they tie. Fields are read through a.json.<field>.

// Sort by business priority, then by most recent date
const rank = { urgent: 0, normal: 1, low: 2 };
const d = rank[a.json.priority] - rank[b.json.priority];
if (d !== 0) return d;
return new Date(b.json.date).getTime() - new Date(a.json.date).getTime();

This type covers what Simple cannot express: an arbitrary business ordering, a normalization before comparison (accents, case, whitespace), a score computed on the fly. If the logic grows long, move it into a proper Code node and sort there instead.

The n8n documentation makes one decisive point: sorting relies on default JavaScript behavior, where elements are converted to strings before comparison. That is the source of trap number one, covered below.

The Limit node: Max Items and Keep

The Limit node has only two parameters:

• Max Items: the maximum number of items to keep. If the input holds fewer, nothing is removed;
• Keep: First Items (keep the first N) or Last Items (keep the last N).

The whole subtlety is that "first" and "last" only mean something relative to the batch's current order. Without a Sort upstream, that order is whatever the previous node produced — not necessarily the one you have in mind.

The Sort + Limit pattern: top-k

Chaining Sort then Limit is the only reliable way to get a "top N" in n8n:

1. Sort in Simple type, field score, Order Descending;
2. Limit, Max Items 10, Keep First Items.

Swapping the two nodes yields a silently wrong result: Limit would take ten items in arrival order, and Sort would only rank those ten. The mistake raises no exception, it just produces a bad ranking — the kind of bug that workflow debugging takes a while to surface.

Worth noting: sorting then truncating is the simplest path, not the theoretically cheapest. On very large volumes, a selection algorithm retrieves the top k without ordering the rest. In practice, modern engines rely on so-called adaptive sorts that exploit the order already present in the data: Vladimir Estivill-Castro and Derick Wood surveyed the field in "A Survey of Adaptive Sorting Algorithms", published in 1992 in ACM Computing Surveys (see on Google Scholar). It is also the principle behind Timsort, the algorithm powering Array.sort() in JavaScript: on partially ordered data — an RSS feed, a chronological export — the real cost of the Sort node is far below what worst-case theory suggests.

Four concrete use cases

• Top 10 highest-scoring leads: after AI scoring along the lines of inbound lead qualification, Sort Descending on score then Limit to 10 with First Items, before pushing to the CRM or Slack;
• The 5 latest items from an RSS feed: the RSS Read node returns entries in feed order, which is not always chronological. Sort Descending on the publication date, then Limit to 5, hardens an automated RSS watch;
• Test sample: Sort in Random plus Limit to 3 at the head of a workflow, long enough to validate a prompt or a transformation without burning the whole dataset;
• Capping a paid API: a Limit right before the call guarantees that an abnormally large source will not fire 2,000 requests. It is a safety net, to be combined with real AI API rate limit handling.

The classic traps

• Lexicographic sorting on numbers: if score holds "10" and "9" as strings, ascending sort puts "10" before "9". Convert with an Edit Fields (Set) node and a {{ Number($json.score) }} expression ahead of the Sort. Typical symptom: a ranking that looks fine up to 9, then goes haywire;
• Dates in the wrong format: 2026-08-25 (ISO) sorts correctly as a string, 25/08/2026 does not — it would group every 25th of the month together. Normalize to ISO or to a timestamp upstream, using the date helpers covered in the n8n expressions guide;
• Null or missing values: an item lacking the sorted field is not dropped, it lands at an arbitrary end of the ranking — and can therefore squat your top 10. Filter those out first, or assign them a floor value with a Set node;
• Limiting is not paginating: Limit kicks in after the data has been received. If the goal is to avoid downloading 10,000 rows, the fix belongs on the request side, through HTTP Request pagination;
• Order is never guaranteed by default: some nodes — parallel calls, aggregations, API responses — do not preserve input order. If order matters downstream (numbering, Summarize, report concatenation), place an explicit Sort just before instead of trusting the order you observed in one test run.

Key takeaways

Sort reorders, Limit truncates, and combining them in the right sequence — Sort first, Limit second — covers nearly every ranking need in n8n. Remember the three parameters that actually matter: Order (Ascending/Descending) on the Sort side, Max Items and Keep (First/Last Items) on the Limit side. And keep in mind that sorting compares strings by default: half of all "inconsistent" sorts are fixed by a conversion to number or ISO date placed right before the Sort node.

Going further

These two nodes come into their own in workflows where volume is the real subject. The AI Inbox Pack (€79) applies that reasoning to email processing: sort by priority, cap the number of messages analysed per run, and surface only what deserves a reply. For document-retrieval workflows where only the best passages should reach the model, the RAG Assistant Pack (€119) shows the same top-k pattern applied to vector database results.