Free Text Repeater

Boundary Value Analysis

Most bugs in form validation don't live in the middle of the valid range. They live at the edges. Boundary value analysis (BVA) means testing at exactly max-1, max, and max+1 characters for a given field limit.

Say your database column is VARCHAR(255). The HTML form has maxlength="255". Does the backend enforce 255 too? Does it truncate silently, throw a 500, or return a proper validation error when you send 256 characters?

Set your repeat count to 254, run the test. Set it to 255, run again. Set it to 256. Each pass tests a different boundary condition. A character like "a" repeated to those exact counts gives you precise, reproducible test strings in under 10 seconds.

One technical nuance: VARCHAR(255) in MySQL utf8 stores up to 255 characters, but a single emoji (U+1F600) uses 4 bytes in UTF-8. If your column uses utf8mb4 and your backend counts bytes rather than characters, the effective limit for emoji input is lower. Worth testing separately.

Security Payload Testing

Input validation testing requires specific injection strings that are tedious to write from memory. A text repeater generates them on demand and lets you repeat them to see whether validation holds under volume.

For SQL injection verification, common test vectors include tautology strings like ' OR '1'='1 and stacked-query payloads like ; DROP TABLE users; --. If your application uses parameterized queries (prepared statements), these should be treated as literal string values, not executable SQL. If they aren't, the form is vulnerable.

For XSS verification, the standard test vector is <script>alert(1)</script>. If the script executes when the page renders, the stored or reflected value is output-encoded.

Event-handler variants like <img src=x onerror=alert(1)> bypass filters that only block script tags.

Repeating a payload 50 times in a single textarea field also checks whether validation logic degrades under volume. Some regex-based validators have catastrophic backtracking behavior that's fine for short input, but locks the server thread on long repeated strings.

These are for testing your own application's defenses, not for attacking external targets.

Whitespace Edge Case Testing

Applications that don't normalize whitespace before processing produce subtle bugs that are hard to reproduce in production. A text repeater makes the input easy to construct.

4 variants worth testing on any text input field:

• Leading spaces: " testuser" — does the backend trim before storage? A username stored as " admin" won't match a login attempt for "admin" unless trim is applied consistently.
• Trailing spaces: "testuser " — SQL CHAR(n) pads to fixed width and treats trailing spaces as insignificant in comparisons. VARCHAR does not. This difference causes matching behavior to diverge between ORM and raw SQL queries.
• Both leading and trailing: " testuser " — tests whether trim is applied on both ends, as strip() in Python and trim() in most languages do.
• Tab-surrounded: "\ttestuser\t" — a tab character is not caught by most naive trim implementations and can break CSV parsers that use tab as a field delimiter.

To build these: paste your string with a leading space into the input, set repeat to 1, and copy. For the tab variant, paste directly with a tab character before and after the text.

Case Sensitivity Testing

Case-insensitive handling should be consistent across your entire stack: frontend, backend, and database. It often isn't.

MySQL with the default utf8_general_ci collation treats "User@Example.COM" and "user@example.com" as equal in WHERE clause comparisons. PostgreSQL does not. If your application normalizes email to lowercase before inserting, but the login query doesn't call LOWER() or use ILIKE, you get inconsistent behavior depending on which database your test environment uses.

Generate your test string repeated in UPPERCASE, lowercase, and Title Case. Submit each to the same field. The response should be consistent across all 3 variants for case-insensitive fields (search inputs, email fields, username lookups) and differentiated for case-sensitive ones (passwords, API keys).

A concrete example: register an account as "User@example.com", then attempt to log in as "user@example.com" and "USER@EXAMPLE.COM". All 3 should succeed on a correctly implemented system. If any fail, the normalization is incomplete.

Unicode and Multi-byte Character Testing

Unicode edge cases surface encoding bugs that only appear at the intersection of your frontend, backend, and database character handling.

4 categories worth covering in any input validation test pass:

• Null bytes (\x00): In C-based string libraries, null terminates the string. Sending "hello\x00world" to a PHP application using older C extensions may result in only "hello" being stored. Modern PDO-based implementations handle null bytes safely, but older code or mixed stacks may not.
• RTL override character (U+202E): used in filenames to hide file extensions visually. The string "report\u202Etxt.exe" displays as "report" followed by reversed text, making an .exe look like a .txt. If your application accepts file names as input, this matters.
• Zero-width joiner (U+200D): invisible in rendered output but present in the byte sequence. "hello" and "hel\u200Dlo" look identical but fail a string equality check. This breaks duplicate-detection logic and unique-constraint validation.
• 4-byte emoji (Example: U+1F600): emoji like 😀 use 4 bytes in UTF-8. A MySQL column defined as utf8 (3-byte max per character) will silently truncate or error on emoji input. The column needs utf8mb4. Test by repeating a single emoji to a count just over the field's character limit.

To test these, paste the specific character (or its escaped form) into the input field, set your repeat count, and submit. Check what the database actually stored against what was sent.

Bulk Test Data With Auto-indexing

For any test that needs unique records, manual entry doesn't scale. Repeat "testuser" 100 times with a newline separator, and you get 100 identical strings, useful for some tests, but not for registration flows that require unique usernames. Enable the auto-index option.

It appends a sequential number to each repetition: testuser_1, testuser_2... testuser_100. That's 100 unique test accounts ready to copy into a seed script, a CSV import, or a direct API payload in under 30 seconds.

The same pattern applies to product SKUs, order IDs, email addresses (testuser_1@test.com), and any field that must be unique across the test dataset.

Specific Payload Size Generation

Load tests and fuzzing often need strings of a precise byte size. If you need exactly 1KB of data, repeat the letter "a" 1,024 times with no separator. That's 1,024 bytes.

For a 10KB API payload, repeat a 100-character JSON fragment 100 times separated by commas, wrap it in brackets, and you have an array with predictable structure and known size. This is faster and more reproducible than generating data programmatically when you just need a quick load test run.

Load-test Payloads

Tools like k6, Locust, and JMeter need input data with a predictable structure. A repeated JSON fragment or CSV row yields a shaped payload without a data-generation script.

Combine a pipe separator with a long string to hit specific payload sizes. Need a 10KB POST body? Repeat a 100-character string 100 times with no separator.

Form-parser Robustness Checks

Beyond field length, a text repeater helps test whether your parsers degrade under repeated identical tokens. A markdown renderer fed 500 identical lines of "bold text" should process in linear time. If it doesn't, you're looking at a quadratic regex. A CSV importer given 500 identical rows should ingest them without choking on the header-to-data ratio.

These are harder to find in unit tests because the inputs are usually small. Generating a 500-line block takes 10 seconds with a text repeater.

Console Log Dividers

Long test runs generate messy log output. A row of 80 equals signs as a section divider makes it easier to scan. Repeat "=" 80 times, copy, and paste into your test setup code. Done.