מפרט החיפוש

Searching by tag does not touch the local index at all. The box normalises what you typed and sends you straight to the profile route, which asks the official Brawl Stars API for that account. Any tag that exists in the game resolves, whether or not this site has ever seen it before — and the profile is written into the local index as a side effect, which is how name search gets a corpus.

Normalisation, in order:

• Surrounding whitespace is trimmed and the whole tag is upper-cased, so tag search is case-insensitive.
• A leading # is stripped.
• O becomes the digit 0 and I becomes the digit 1 — those letters do not exist in Supercell tags, so typing them is treated as the obvious mistake rather than as an error.
• Anything that is not a digit or a letter is removed.

The result must then be 3 to 14 characters long and use only the tag alphabet 0289PYLQGRJCUV. Anything else is rejected in the form before a request is made. Club tag search works identically.

A tag the API answers with 404 shows a not-found page, and the background refresh queue drops that tag from the local index the next time it comes up — as does the player search page when it fetches that tag for a results list — so a deleted account stops appearing in name search and stops consuming refresh budget.

The official API has no name lookup of any kind. Name search therefore runs entirely against this instance’s own SQLite index of players and clubs it has already seen. If nobody has ever opened a given player here and that player has never appeared on one of the leaderboards this instance bootstrapped from, a name search cannot find them.

שחקנים שמעולם לא נצפו כאן אינם מופיעים בחיפוש לפי שם. חפשו אותם פעם אחת לפי תג והם ייכנסו לאינדקס.

How a player search query is matched:

• The query is trimmed and lower-cased, and compared against a lower-cased copy of the name. Matching is therefore case-insensitive; it is not accent- or width-insensitive, so é and e are different characters.
• An empty query returns nothing — it is not treated as “list everyone”.
• By default a query is matched three ways at once, and the results are merged:
  • From the start of the name. fang finds Fangirl, and toxicfang finds ToxicFang. This way searches every indexed player, however few trophies they have, and it reads at most 2,000 names.
  • From the first letter or digit, when a name begins with something else. The run of characters in front of the first letter or digit — symbols, emoji, flags, punctuation, brackets, and the invisible filler characters some names start with — is skipped, and your query goes through the same rule, so fang and ☆fang both look for names whose letters begin fang. Only the run at the very front is skipped; nothing later in the name is. This way also searches every indexed player and reads at most 2,000 names. It is not switched on on this server yet: it needs a one-off index build, and until that has run only the other two ways are used.
  • Anywhere inside the name, but only across the 5,000 players with the most trophies. This is what finds a name where the part you remember sits in the middle.
• What the second way recovers, measured on a copy of this site’s index taken on 17 September 2026 (6,279,958 players), by typing the word you can read: fang puts ★FANG★ (35,546 trophies) 30th on the page, where before it was not on the page at all; mestre67 puts (MESTRE67) (3,010 trophies) first; bienio puts ♠️Bienio♠️ (112,170) first; shark puts 🌊🦈Shark 🦈🌊 (148,323) 9th. On that copy 536,729 names (8.5%) begin with characters this way skips. For 470,949 of them something is left after the skip, and that is what the second way searches; the other 65,780 are nothing but symbols, and only typing those symbols finds them. Of 2,000 of the 470,949 picked at random and searched by the first word a person would type, 2 were on the page before and 1,081 (54.0%) are now; typing the longer start of the name raises that to 1,281 (64.0%). For comparison, 2,000 random names with nothing in front are found by their first word 76.0% of the time. Why the rest still miss is under “What name search still cannot find” below.
• Those numbers are the honest edge of this search, so here is where it bites. Below the top 5,000 — on the 17 September copy, everyone under 170,724 trophies, which is 99.92% of the players indexed — a player is found only if what you typed is the beginning of their name, or the beginning of what follows the symbols in front of it. Above that line, matching anywhere in the name still works exactly as it always did.
• Typing more characters does not fix a miss. Typing characters further left does. Extending a fragment to the right never helps, because the start-of-name ways only ever compare against the front of the name. Measured on a real account called XxBladedFrostxX (20,045 trophies, below the line): bladedfrostxx — thirteen of its fifteen characters — finds nothing, while xxblade finds it; on the 17 September copy bladed and bladedfrostxx still find nothing with all three ways switched on. For 銀💙Kurihana迪熊🧸 you still have to reproduce the 銀 and the emoji: 銀 is a letter, so nothing is skipped, and kurihana finds nothing before or after the change. 💙kuriha misses and 銀💙kuriha hits.
• How many results you get changed too, and an earlier version of this page was wrong about it. It said a query of one or two characters returned exactly what it used to. Re-measured across 29 queries — ASCII and non-ASCII, one character through eight, common, rare and one matching nothing at all — 25 of them filled the old 100-row page, and of those only a and ar come back unchanged. Those two were the entire evidence base for the sentence that has now been removed. Of the old 100 results, what survives is 100 for a and ar, 85 for q, 50 for 8, 10–26 for a single non-Latin character (€ 10, 好 17, ж 22, ★ 26), 24 for bra, 18 for brawl, 5 for zzq.
• The places this frees up are filled with start-of-name matches the old ranking pushed off the page — every single replacement row, across all 29 queries, was one. But they only fill if enough names actually start with what you typed. A search returns at most the names starting with your query (up to 2,000) plus the names whose letters, after the symbols in front, start with it (up to 2,000) plus the top-5,000 players whose name contains it, so when fewer than about a hundred names share your beginning the page is simply shorter than it used to be. Measured on the live index when the caps arrived, brawlers went from 100 rows to 55, 0o to 56 and zzq to 6. On the 17 September copy, with only the first and third ways, brawlers returned 66 rows, 0o 64 and zzq 6; with all three, brawlers returns 69, 0o 73 and zzq still 6 — 116 players on that copy have zzq somewhere in their name. A term distinctive enough that every account carrying it already starts with it is unaffected: toxicfan and фанг return exactly what they always did.
• What did not change is the top of the table. Across all 29 queries the highest-trophy result that was lost had 170,108 trophies — below the 170,378 floor of the match-anywhere window. Every dropped row without exception was a mid-name match on a player under that line.
• %, _ and \ in your query are escaped before the query runs, so they match themselves instead of acting as wildcards. There is no wildcard syntax exposed to the user.
• Results are ordered by the trophies stored in the index when the search runs, highest first, then cut to the result limit.
• Most indexed players have never had their own profile fetched. They are known only by the tag and name that appeared in somebody else’s battle log, a club roster or a leaderboard, so the index holds no current trophy count of theirs worth showing. They are still ordered by whatever figure the index holds: a battle-log row carries a placeholder zero and sorts last, while a club-roster or leaderboard row carries the figure that list showed when it was read, of unknown age, and sorts wherever that figure puts it — above or among fully indexed players. Either way the row shows “loading” instead of that figure. As they scroll into view the page asks the official API for their real profile — the same fetch a player page makes — and fills in the trophies, icon and club in place. A row that loads keeps its position and its height, so the list does not move under your finger; searching again sorts it by its real trophies. A profile the API is slow to return keeps loading in the background and fills in when the row asks again. If the profile cannot be fetched (the account no longer exists, or the site is limiting these requests — see Limits below) the row says so rather than showing a number.

Club name search is trimmed, lower-cased, wildcard-escaped and ordered by club trophies descending in the same way, but it is a plain substring match over every club, with no cap and no split into two halves. It can afford to be: there are about 1,400 clubs indexed against more than five million players, so reading the whole club table costs well under a millisecond whatever you type. Clubs have no exact-match or previous-names option. If what you typed is itself a valid tag, both search pages also offer a direct link to that tag.

Every example here was measured on the 17 September 2026 copy of the index with all three ways switched on, reading the 100 results the search page shows. Every named player is below the top-5,000 line.

• A word from the middle of a name. bladed does not find XxBladedFrostxX (20,045 trophies). Only letters at the very front are compared.
• A name that starts with a letter used as decoration. Characters such as 銀, 亗 or ツ are letters, so they are not skipped: kurihana does not find 銀💙Kurihana迪熊🧸 (169,794 trophies). On the copy, 951 names start with 亗, 850 with ツ, 447 with 乂 and 208 with 彡 followed directly by a Latin letter.
• Styled or full-width letters. Letters like 𝐀𝐛𝐢𝐧𝐧𝐢 are different characters from Abinni, and nothing converts one into the other: abinni does not find √|𝐀𝐛𝐢𝐧𝐧𝐢⚝ (31,989 trophies), while pasting 𝐀𝐛𝐢𝐧𝐧𝐢 puts it first. 53,268 of the 470,949 names searchable by their first letter start with styled, small-capital, superscript or full-width letters. In the random sample of 2,000, 235 did, and 14 of those were found by the word a person would type.
• The name behind a bracket tag. Only symbols are skipped, not the tag inside the brackets, so the tag is where the name starts: nekon does not find [AU]Nekon (56,724 trophies) and au puts it 89th; killer does not find [ARK]KILLER (42,874) and ark puts it 73rd.
• A common word on an account with few trophies. Results are ranked by trophies and cut at 100, so when more than a hundred higher-ranked players match the same word, a low-ranked one is not shown. Of the 919 accounts in the random sample of 2,000 still missed by their first word, 547 were missed this way — 1,899 of those 2,000 accounts have a stored trophy count of zero, because they are known only from someone else’s battle log or club roster. The other misses were the 221 in styled letters and 151 whose first readable word is not how their name actually continues after the symbols.
• Some accounts that used to sit at the bottom of a full page. The second way adds real matches, and on a page that already held 100 results they can push the last few off it. Of 2,000 random names with nothing in front, searched by their first word, 8 that were on the page before were not after: every one had a stored trophy count of zero and sat between 96th and 100th. Two of the eight had a longer name, and typing it (robi xd, boy 2) still put them first; the other six are one common word.
• Previous names, and exact match. Neither option below uses the second way: an old name that began with symbols still needs them typed, and exact match still compares the whole name.

The two checkboxes under the player name box refine how a name is matched. Both are available to everyone — no account is needed, and they work the same whether you tick them on the page or set exact=1 and prev=1 on the URL yourself.

Name history only goes back as far as this instance does. It is built by noticing that a tag we already had is now reporting a different name, so a rename that happened before the account was first indexed here is invisible.

These are the paths that put a player or club into the local index.

1. Page views. Opening a player or club page fetches the profile and indexes it: the account row itself, a name-history row, a club-history row, an hourly progression snapshot, the equipped skins, and any ranked tier label the profile carries. This is the main way the corpus grows, and it means a tag becomes name-searchable the first time anyone looks it up here.
2. The leaderboard bootstrap. On the first start with an API token configured, the app walks the official player and club leaderboards for global, TW, JP, KR, US, BR, DE and MX and writes what those rows carry — tag, name, trophies, icon, club name — so that a brand new instance is not returning nothing for every query. These rows are deliberately stored as summaries with an empty profile payload and a back-dated update time: they are searchable by name immediately, and the background refresh queue fills in the full profile later. The bootstrap runs once; the flag that records it lives in the local database.
3. Battle logs and club rosters. Every archived battle names the other players in it, and every fetched club lists its members. Those accounts are written into the index as name-only rows so they can be found by name before anyone has opened their page, and they are by far the largest part of the index. A battle-log row carries only a tag and a name; a club-roster row also carries the trophies and icon the roster listed when the club was fetched. Neither is treated as the player’s profile: each waits in the refresh queue for its first real fetch, and the player search page fetches it sooner when it appears in a results list.
4. The refresh queue. Once a tag is indexed it is re-polled on a schedule, which is how a renamed account’s new name and its name history stay current without anyone visiting the page.

With no API token configured the site runs in demo mode and seeds the index with deterministic synthetic players and clubs so the search boxes do something. Those rows are recorded as synthetic and are deleted in full the moment a real token appears, so they can never leak into live results.

Every cap on this page exists for one reason, so it is worth stating the number it buys. These are whole-request timings — the complete page request an anonymous visitor makes, not one query inside it — measured against the live index of 5,321,046 players and 5,154,798 recorded names.

Before the caps, the default search took as long as the word you typed was rare, because it walked the trophy table from the top until it had collected enough matches. A common query finished instantly; a rare one read every row. Measured:

The worst case now is not a rare query at all — the caps made rare queries the cheap ones. It is a single character with both refinements ticked, which has to touch a fresh part of three different indexes: 44 ms typical, 156 ms worst observed, swept over 171 different first characters covering Latin, Cyrillic, Greek, CJK, kana, symbols and emoji. Repeated searches settle at 2–8 ms.

What that protects is other people. With one visitor typing a rare name over and over, an ordinary player page used to take 1,583 ms to answer instead of its usual fraction of a millisecond, and only 7 of the ~400 page requests due in ten seconds completed at all. With the caps in place the same test serves 321–374 of them, at a median of 1 ms.

The first-letter-or-digit way was measured separately, on the 17 September 2026 copy of the index (6,279,958 players, 470,949 of them searchable that way). These figures are the search function the results page calls, asking for 100 results, in a fresh process — not a whole page request like the table above. On its own, over every one of the 5,437 different first characters those names start with after the skip, it took 0.06 ms at the median and 7.2 ms at worst. For whole searches, the first time each query ran, one character or a common word took 7.6–21.2 ms with it and 6.9–18.6 ms without it across two runs; rare queries (zzq, qzxjvkwq, toxicfan) took 1.8–2.5 ms either way; with previous names ticked, 17.4–35.3 ms with it and 18.1–33.6 ms without. For repeated searches the median changed by between 1.3 ms faster and 1.0 ms slower, or up to 1.9 ms slower with previous names ticked; the same database measured twice varied by up to 0.9 ms, or 1.2 ms with previous names ticked.