Which character Among Us accepts
Among Us accepts U+318D. An update added a server-side check that returns 'Server refused username' for a name with no visible content. U+318D Hangul Letter Araea is a Hangul vowel that draws as a single small dot — it is deliberately not invisible, which is what passes the check. Verified properties: General Category Lo, White_Space=No so no field trims it, 3 bytes in UTF-8. NFKC folds it to U+119E, so a platform that normalizes stores a different codepoint. U+3164 Hangul Filler still works in Local and Freeplay, where no server validates.
The fallback is U+3164, which clears validators the first character does not. Both survive trim(), which is the operation that destroys an ordinary space.
The field caps at 10 characters, and every invisible character counts as one. A name of 10 invisible characters is the maximum Among Us will store.
How to set it on Among Us
To set blank text on Among Us, copy the character above and paste it into a cleared field. The whole method is one paste — the cost is free — the name is set per session, not per account.
- Copy U+318D Hangul Letter Araea from the tool above — it renders as a single small dot.
- Open Among Us and tap the name field on the main screen.
- Clear it and paste.
- Join an online lobby to confirm the server accepts it.
On Android
Copy the character, open Among Us, clear the field and long-press to paste. If the paste produces nothing, the keyboard's clipboard manager stripped it — copy from the browser directly rather than from a clipboard history panel.
On iPhone and iPad
iOS sanitises some pasted content between apps. Paste the character into Notes first, select it there, copy again, then paste into Among Us. The second copy comes from a plain-text source and survives.
On desktop and emulators
Desktop clients paste the character unmodified, so the browser-to-app route works directly. Android emulators such as BlueStacks and LDPlayer share the host clipboard, and pasting into the emulator's own notes app first avoids the same stripping that affects physical devices.
Why an invisible character works where a space does not
One Unicode property decides it, and it is not the one most guides name. Every character carries a White_Space value of Yes or No, and that value determines whether trim() removes it.
The spacebar produces U+0020, whose White_Space value is Yes. Among Ustrims the field before saving, the trimmed value is empty, and the field falls back to its previous contents. That is why a name built from spaces looks correct in the editor and reverts the moment you save.
U+318D has White_Space=No. No trimming function removes it and the regex class \s does not match it, so the value that reaches the server is the value you pasted.
One caveat applies to U+3164 specifically. Normalization Form NFKC folds it to U+1160 Hangul Jungseong Filler, so a platform that normalizes before storing keeps a different codepoint than the one you pasted. The name still displays blank. Use U+1160 directly if you want the stored value to match exactly.
What it costs on Among Us
Free — the name is set per session, not per account. Nothing is consumed by a failed attempt, so trying a second character costs only the time.
If it does not work on Among Us
If you see 'Server refused username', the name had no visible character. Use U+318D, which reads as a single dot and passes the check while staying almost invisible.
The field clears itself after saving
Among Us trimmed the value and found an empty string, so it restored the previous one. The character you used has White_Space=Yes. Switch to U+318D or U+3164, which do not, and the value survives the trim.
A box or question mark appears
The rendering font has no glyph at that codepoint, so the renderer draws.notdef — an empty rectangle in most fonts. The stored value is correct and only the display is wrong. U+3164 carries wider font coverage than most alternatives.
The paste produces nothing on mobile
The keyboard or clipboard manager sanitised the content in transit. Paste into a plain-text notes app first, copy from there, then paste into Among Us. This is the single most common practical failure and it has nothing to do with the character itself.
It works on desktop and fails in the app
The two clients validate separately. A value the desktop site accepts can still be rejected by the mobile client's own check, and the reverse also happens. Set it on whichever client accepts it — the stored value is shared.
Full property data for both characters is on the Unicode invisible characters table.
Is a blank name allowed on Among Us?
Yes. A blank name breaks no Among Us rule. Platform policies restrict impersonation, harassment and filter evasion, not which codepoints a name contains.
Two uses do violate policy on Among Us and on every comparable platform, and neither depends on the name being blank. Copying another user's name to pass as them is impersonation. Splitting a blocked word with a zero-width character to defeat moderation is evasion.
One consideration applies regardless of the rules. Screen readers announce nothing for an invisible character, so NVDA, JAWS and VoiceOver read a fully blank name as unnamed. Keeping one visible character alongside the invisible ones preserves the announcement and still looks almost blank.