A separator is the literal string placed between list A and list B for every pair, and the Keyword Combiner accepts any literal up to 20 Unicode code points provided it contains no line breaks or control characters. Common choices include a single space, a hyphen, a plus sign, an underscore, or an empty string, and each one changes how the final phrase reads and whether two different pairs can collapse into the same output. The separator is inserted verbatim with no hidden padding, so red plus shoes becomes red shoes with a space and redshoes with an empty separator. Choosing a separator is therefore a decision about phrase shape rather than the tool's mechanics: the widget will combine every pair deterministically no matter what you type, but the resulting text has to match the format expected by your spreadsheet, ad group, or content brief. If two distinct pairs produce the same final phrase, the tool keeps the first occurrence and reports the later one as a collision rather than silently dropping it, which matters most when the separator is short enough that distinct concatenations can collide.
What the Keyword Combiner Accepts as a Separator
The separator field is a literal text box, not a dropdown. The widget validates what you enter against a small set of rules rather than guessing what you meant. A valid separator can be an empty string, a single character, a short word, or any literal up to 20 Unicode code points. The characters you type are preserved exactly, which means internal spaces, punctuation, accents, emoji, and non-Latin scripts all survive untouched. The tool does not normalize your separator, capitalize it, or replace it with a synonym.
Three constraints matter most:
- No line breaks. You cannot paste a separator that contains a newline, carriage return, or Unicode line separator, and the input rejects those characters before any combination runs.
- No control characters. Control code points are blocked for the same reason.
- Maximum length of 20 Unicode code points. A separator longer than that fails validation, and the request is refused before any pair is produced.
Because the separator is preserved exactly, what you see in the field is what appears between every pair in the output. There is no invisible padding or trimming.
How to Pick a Separator That Fits Your Use Case
The right separator is the one that produces the shape of phrase your downstream tool expects. The Keyword Combiner does not change phrase casing or add match-type syntax, so the separator is the only place where shape enters the result.
| Separator | Example output (A=red, B=shoes) | Typical use |
|---|---|---|
| Empty string | redshoes | Domain names, portmanteau tokens, compact identifiers |
| Single space | red shoes | Natural-language phrases, content briefs, ad-group drafts |
| Hyphen (-) | red-shoes | URL slugs, hyphenated compounds |
| Underscore (_) | red_shoes | Filenames, code identifiers, database columns |
| Plus sign (+) | red+shoes | Legacy keyword exports, explicit token joins |
A space is the default for natural-language phrases such as red shoes or cheap flights to london. It is the safest choice for content briefs, ad-group drafts, and any human-facing list where readability matters.
A hyphen is the conventional separator for URL slugs, hyphenated compounds, and many SEO crawlers. red-shoes reads as one slug, and most analytics tools treat hyphens as word boundaries inside an identifier.
An underscore is useful when the destination is a filename, a code variable, or a database column. red_shoes keeps the two parts bound together without looking like a typo to most readers.
A plus sign is sometimes used in legacy keyword research exports and in some old-school match-type conventions. Treat it as a literal token rather than as an actual operator, because the widget never adds Google Ads syntax for you.
An empty string merges two terms into a single token. This is the right choice when you are building domain names, portmanteau brand names, or compact identifiers where whitespace would be wrong, and it is also the case where collisions between distinct pairs are most likely.
Enter the Separator and Run the Combination
- Paste one keyword or phrase per line in list A and one modifier or second term per line in list B. Each non-empty line is trimmed at the edges, empty lines are ignored, and exact case-sensitive duplicates inside a list are removed in first-seen order.
- Choose either A-then-B or B-then-A. The order controls which list is iterated as the outer loop, so the order in which pairs appear in the output changes accordingly.
- Enter the separator exactly as you want it to appear between the two halves of every pair. A single space is the most common starting point. If your separator has leading or trailing whitespace from a copy-paste, clear it, because nothing is trimmed from the separator field.
- Combine the complete pair set. The widget computes the theoretical pair count first and refuses any request that would exceed 10,000 input pairs, which prevents a near-cap request from slipping through only because of later duplicates.
- Review the summary block. It shows the unique output count, normalized list sizes, theoretical pair count, removed input duplicates, and removed output collisions. Use those numbers to decide whether to narrow the lists, change the separator, or both.
- Copy the deterministic one-per-line output. Because the order is stable, rerunning the same input produces the same text, which makes the result suitable for diffing between runs.
How Separator Choice Changes Final Phrases
The same two lists behave very differently depending on what sits between them. Consider list A equal to red, blue, green and list B equal to shoes, hat.
With a single space, the output reads as six natural phrases: red shoes, red hat, blue shoes, blue hat, green shoes, green hat. All six pairs are readable as standalone phrases.
With an empty separator, the same six pairs collapse to redshoes, redhat, blueshoes, bluehat, greenshoes, greenhat. The pairs still exist, but every phrase is one continuous token, which is useful for domain names and brand-name experiments but harder to read.
The empty separator also exposes collisions that the space separator hides. ab plus c and a plus bc both produce abc when the separator is empty, so the second occurrence is reported as an output collision and only the first copy survives. With a space, the same two pairs produce ab c and a bc, which are distinct phrases and never collide.
If your final count looks unexpectedly small compared with the theoretical pair count, the cause is usually either duplicated source lines or colliding concatenations. Switching to a longer separator is one of the fastest ways to separate near-collisions before you copy the result.
Common Separator Mistakes and How to Debug Them
Most separator problems come from invisible characters or from picking a separator that does not match the destination format. A few patterns cover most of what goes wrong.
A pasted separator that looks like a space but is actually a non-breaking space or a thin space passes visual review and silently produces phrases that look correct on screen but fail downstream parsers. The widget preserves both characters because both are valid Unicode, so the cure is to retype the separator manually rather than to trust the paste.
A separator that contains a line break is rejected outright. This often happens when the separator is copied from a multi-line document and an accidental return comes along with it. The fix is to enter the separator as a single short line.
An empty separator chosen by accident merges terms into unreadable tokens and inflates output collisions. If the summary shows many collisions and the output looks jammed together, that is the diagnostic.
A separator that is too long, meaning more than 20 Unicode code points, fails validation before any combination runs, which is the same behavior as an empty list: no partial output, no truncation, just a refused request. The fix is to shorten the separator or to split it into two steps.
A separator chosen for one destination copied into another destination that expects a different shape, for example a space copied into a slug generator or a hyphen copied into a content brief. The output is mechanically correct but operationally wrong, so always match the separator to the consumer of the list.
For readers who want to see separator choice in context alongside order and pair counts, the guide Combine Keyword Lists: Order, Separator, and Pair Counts walks through the same controls together. The widget itself lives at the Keyword Combiner tool page, where separator, order, and pair budget can be tested directly in the browser without uploading either list.
For a deeper look, see Keyword Density Checker Explained: What the Numbers Mean.