The Invisible Character That Cost Me Too Much Debugging Time The Problem A user failed to log in despite correct credentials. The email looked normal: james.bond@mi6.com. Logs and database showed no issues, but authentication failed. Investigation revealed a zero-width space (invisible Unicode character) between "bond" and "@". Visually identical strings were different at the byte level, causing login failures. How Does Something Like This Even Happen? Invisible or confusing characters often come from: Copy-pasting from PDFs or Word documents — hidden control characters. Email clients or chat apps — soft hyphens, directionality markers, non-breaking spaces. Keyboards and IMEs — combining marks or zero-width joiners. The registration process accepted such characters because: Regex validation passed. Database insertion had no issues. The API payload appeared normal in JSON. But manual user input during login didn’t include these invisible characters, resulting in mismatched comparisons and authentication failures. Other tricky characters include: Soft hyphen (U+00AD): invisible unless line-breaks occur. Left-to-right/right-to-left markers (U+200E, U+200F): disrupt string rendering. Homoglyphs: visually identical characters from different scripts (Latin "a" vs Cyrillic "а"). Testing What You Can’t See Most test suites miss these edge cases. Typical testing handles missing fields or SQL injection but not invisible characters, zero-width spaces, or homoglyphs. These bugs often emerge only after developers encounter issues. Enter Dochia Dochia is an open-source tool that automates systematic negative and boundary testing for APIs, focusing on hidden input bugs, missing fields, oversized payloads, and more, independent of business logic. How it works: Takes an OpenAPI spec. Generates smart, crafted test payloads. Sends requests and produces detailed reports with exact payloads, responses, and anomaly explanations. Example command: Dochia quickly finds tricky input bugs without manual guesswork. Additional Bugs It Found Dochia uncovered many subtle bugs beyond zero-width spaces: Passwords with null bytes (\x00): backend truncated input, allowing partial-password logins like hunter2\0evil matching hunter2. Unicode minus sign (U+2212): negative ages like –25 (unicode minus) were accepted, bypassing input validation. Duplicate usernames bypass: e.g., john vs john<U+200B> stored as distinct users, confusing duplicate checks. Emoji handling: usernames with emojis (like alex🙂) stored fine but broke UI rendering due to incorrect assumptions about character width. These examples come from various projects but share the root cause: missing edge case handling for user input. Why Share This? Invisible character bugs are common pitfalls for all developers dealing with messy, unpredictable user input—not just big companies. Dochia is free and open source: Run it to find hard-to-spot bugs in your system. The Reality of User Input Users rarely type clean ASCII—they paste text from varied sources, use different keyboards, browser extensions, proxies, and more. Every layer introduces noise. Assuming "well-formed UTF-8 strings without weirdness" will eventually lead to wasted hours chasing invisible bugs. You can catch these surprises early with tools like Dochia or spend days on frustrating debugging. --- Resources dochia.dev — main site GitHub: dochia-cli — source code Documentation --- Got a weird bug story? The zero-width space was just the start.