Random text generator
Transformed in your browser · nothing is uploaded
Produces text of a size you set, so you can put a known quantity through a field, a template or an import and see where it gives way. Despite the name the output is fixed rather than random: the same count returns the same text, which is what makes a failure reproducible.
How to use the random text generator
The name is wrong in a way worth correcting, because it changes what you can use this for. The output is not random; it is a fixed sequence, and the same count always returns the same characters. For testing that is the property you want — a failure at 256 characters that cannot be reproduced tomorrow is not a bug report, and it is precisely why this is no use for anything that needs unpredictability. A password, a token, an ID or a shuffle needs a cryptographic source and belongs to a generator built for it. This produces text of a known size and nothing more.
That known size is the point. A column declared at 255 characters wants to be tested at 255 and at 256, because the interesting behaviour is at the boundary: whether the write is refused with a usable error, silently truncated, or truncated in a way that cuts a multi-byte character in half and leaves an invalid string behind. The same applies upward through the stack: a form validating at one limit against a database enforcing another is a common mismatch, and it only ever shows up at the edge. Layouts fail at a boundary too, a blurrier one: a heading style built around three words rarely survives fifteen, and a card grid that looks even with matched summaries goes ragged when one is twice the length of the rest.
The blind spot is what this text is made of. It is unaccented ASCII Latin, all short words, no punctuation to speak of, no digits, nothing right-to-left and nothing outside the basic plane. So a field that accepts a thousand characters of it can still fail on a single é, an emoji that counts as two UTF-16 units, an Arabic string that reverses the layout, or a name containing an apostrophe. Passing a length test with this proves the length handling and nothing about the encoding handling, and those are the two ways text input usually breaks. Test the second with real awkward strings, not with filler.
What people use it for
- Filling a field to its stated maximum, then going one character over
- Producing a fifteen-word heading to stress a layout designed for three
- Checking whether a truncation rule cuts on a word boundary or mid-word
- Feeding a seeded test fixture body text that will not change between runs
- Loading an import with rows of a known size before the real data arrives
Questions
No. The same count returns the same text, which is deliberate: a failing case has to reproduce or it is not worth reporting.
No. This is fixed filler. Anything that must be unpredictable needs a cryptographic random source, which is a different tool entirely.
Yes, choose Words and set the count, up to the two-hundred cap. For an exact character count, generate a little over and trim.
It proves the length handling. It is plain unaccented ASCII, so a field that survives it can still fail on é, an emoji or a right-to-left string.
The stated limit and one more. The interesting failures are a silent truncation, or a cut that splits a multi-byte character and leaves an invalid string.
It is the standard scrambled Cicero passage, so Latin words in a meaningless order. The lorem ipsum page has the history.
Two hundred of whatever unit you chose. Two hundred paragraphs is well past any layout test; on the Words tab the same cap means two hundred words, so generate paragraphs when you need a longer block.