Video Tag Builder

The tag field on a video upload form is one of the least glamorous boxes on the internet. It takes a list of words and phrases, separated by commas, and it says almost nothing about what happens to them afterwards. A great deal of advice treats that box as a lever. This page takes the opposite view: tags are a minor descriptive field, and the title, the thumbnail and the description carry far more of a video’s meaning. That view is the tool’s own, not a quotation from anyone.

If the field matters little, why build anything for it? Because small fields still have rules, and those rules bite in quiet ways. A list can be too long and be cut. A tag can be typed twice with different capitals. A phrase can count for more than it seems to. None of that is about ranking. It is about handing the form a list that says what you meant, in the order you meant it.

A list with a hard end

The platform’s own developer reference is the clearest statement of the rules that could be found under a licence this site can use. Its page on the Videos resource, read on 2026-10-20, says the tag list has a maximum length of 500 characters. It adds two details that most people never notice. The commas between tags count toward that limit. And a tag that contains a space is handled as though it were wrapped in quotation marks, with the quotation marks counted too. Its own example: Foo-Baz counts as seven characters, but Foo Baz counts as nine.

That is a published API reference, not a promise, and it can change. It also leaves two things open. It names no limit for a single tag, and it never says what a character is. The tool therefore treats the total limit, any per-tag limit and the counting unit as your settings, starts them at what that page states, and says so on screen.

Once there is a total limit, a tag list stops being a bag of words and becomes a queue. Whatever sits at the front is safe. Whatever sits at the back is the first to go. So the useful question is not which tags to add, but which ones you would give up first, and the answer should be decided by you before a limit decides it for you.

That is why the tool takes your words in three boxes instead of one. The first holds the core topic, the second the specific details, the third the broad context, and a fourth box takes a list pasted from somewhere else. Order runs core, specific, broad, pasted, each in the order typed, until you move a tag yourself with buttons or the keyboard. The order is stable: the same words always give the same list.

When the list is too long, the cut happens at a tag boundary. The tool walks the queue from the front, adds each tag and the comma before it, and stops at the first tag that does not fit. Everything after that point is listed as cut, in order. It never trims the last tag to squeeze in a fragment, and it never pulls a shorter tag forward from further back, because either move would quietly overrule the order you chose.

In the tool’s own tests, five thousand random lists under all four counting rules produced no line over its limit and no tag cut in half. Every one of those cuts landed between two tags.

Counting in the right unit

Here is the part that surprises people. The word character hides at least four different counts, and a limit stated in one of them can be broken while another reads well under it.

What a reader sees as one character is a grapheme cluster, which a browser can find with the segmenter MDN describes. A JavaScript string’s length is a count of UTF-16 code units, so anything outside the basic plane takes two of them, as RFC 2781 sets out with its high and low surrogate pairs. Underneath both sits the code point, one per Unicode character. And UTF-8, the encoding RFC 3629 defines and a browser’s TextEncoder writes, spends one to four bytes on each code point.

For plain English text the four counts agree, which is why nobody notices. They part company the moment a list holds an accent, a Japanese word or an emoji. A family emoji built from three people and two joiners is one character to a reader, five code points, eight UTF-16 units and eighteen bytes. The RFC’s own example, the three characters of the Japanese word nihongo, is nine bytes. Neither number is wrong. They are answers to different questions.

A worked example makes the stakes concrete, and you can reproduce it on the page. Load the example list, which has forty different tags after duplicates are removed, and leave the defaults: a limit of 500, commas counted, quotation marks counted. Counted in code points, thirty tags fit and the line comes to 494 of 500. The next tag, banneton, would need its comma and eight more, which makes 503, so it and the nine after it are cut. Now switch the unit to UTF-8 bytes.

The Japanese word for sourdough in the list is five code points but fifteen bytes, and a tag that mixes English with a Russian word grows from fourteen to eighteen. The line drops to twenty-nine tags and 488 bytes, and high hydration dough falls off the end.

The reference page does not say which of these units it means. The strictest reading is bytes, and a list that fits in bytes fits under every other count. That is a choice, not a fact about the platform, so the tool shows it as one.

The same tag twice

The commonest flaw in a tag list is repetition: the same idea typed twice, once in capitals, once with an accent composed differently, once with a stray number sign in front. A visitor rarely means to do this. The tool cleans each tag first. It trims and collapses spaces, takes off a leading number sign, removes a comma left inside a tag and removes invisible control characters, then lists every change so nothing happens behind your back.

Comparing two tags fairly needs more care than lowering their case. The Unicode case folding file exists for exactly this job, and its full form uses the mappings marked C and F, 1,606 of them in version 18.0.0. Full folding is what lets a German sharp s match a double s, and a Greek final sigma match the ordinary one. The file also warns that folding does not preserve normalization, so the tool decomposes first, folds, and composes again, which is the canonical equivalence MDN describes for the normalize method.

Folding is used only to compare. The first spelling to appear, in priority order, wins and keeps the capitals you typed; later copies are removed and named. Look-alike letters from different scripts are a separate matter. A Latin a and a Cyrillic a can look identical, but they are different characters and different tags, so the tool keeps them apart and flags any tag that mixes scripts.

Near is not the same

Exact duplicates are mechanical. Near duplicates are judgement, and that is where a tool should hold back. The page measures Levenshtein distance, the smallest number of single-character insertions, deletions and substitutions that turns one string into another. The classic example, kitten to sitting, takes three. Pairs one or two edits apart are flagged, with the second edit checked only when both tags have at least five characters.

It also pairs English singular and plural forms by a deliberately small rule set. It is taken from the regular patterns: add s; add es after a sibilant such as ss, x, ch or sh, and after many words ending in a consonant and o; change a consonant and y to ies, as in cherry and cherries. Irregular plurals, other languages and other scripts are not paired, and the page says so.

Then it stops. A flagged pair is shown with two buttons and nothing is removed for you, because a near duplicate is often the point. A bread video might want both levain and levian, two edits apart, if levian is how some of its viewers type the word, because a misspelling people really type is a fair description of what they are looking for. Two spellings of one word, such as colour and color, can earn their places for the same reason. The tool cannot know which pairs are mistakes. It can only make sure you have seen them.

What a careful list cannot do

Nothing on the page knows whether a tag will help anyone find a video. It has no search data, makes no request and shows no volume or ranking figure, so it cannot rank tags, suggest new ones or promise reach. It cannot tell you how the platform counts characters beyond what the reference says, or whether that rule still holds tomorrow. The title check only reports shared words; repeating the title can be exactly what you want.

What it can do is narrow and checkable. Your list leaves the page as one comma-separated line, as one tag per line, as a CSV and as a JSON file you can open again. The CSV follows RFC 4180 quoting, and any cell that starts with an equals, plus, minus or at sign gets a leading single quote, the guard OWASP describes against spreadsheet formula injection. Those outputs are the whole product: a short, tidy list in your own order, counted the way you chose.