How the mockup is built
The interface is deliberately minimal: one text area and a preview. Each line becomes a message bubble, in order, and blank lines are ignored. Starting a line with a greater-than sign marks it as your own message, so it renders on the right in the familiar outgoing color; every other line renders on the left as the other person. That is the entire input format.
The image is drawn on an HTML canvas rather than screenshotted from the page. Text is measured and wrapped to about seventy percent of the frame width, bubbles are drawn with rounded corners, and the canvas height grows to fit however many messages you wrote. It is rendered at twice the display resolution, so the PNG stays crisp when it lands in a slide deck or a design file.
Everything happens in the browser tab. The conversation text is never sent anywhere, the rendering is local, and the download comes from memory. If you are mocking up something confidential for a product review, it does not leave your device.
- One line per message, in order, with blank lines skipped
- A leading greater-than sign makes a message yours
- Rendered locally on a canvas at double resolution and saved as PNG
What it deliberately does not render
This is a simple bubble renderer, and it is worth being clear about the gap between that and a real screenshot. There are no timestamps, no delivery or read receipts, no avatars, no contact name header, and no phone status bar with a clock, signal bars, and a battery indicator. There are no reactions, no replies quoted above a message, no images or voice notes, and no wallpaper choice.
The colors are fixed to the familiar palette for the style: a warm neutral background, a pale green bubble for your own messages, and white for the other person. There is no theme switcher, no dark mode, and no custom color control.
That makes it well suited to what it is actually good for. A conversation flow in a product spec, an illustration in a blog post about messaging, a slide showing how a support exchange should go, a placeholder in a design comp. It is not suited to producing something intended to look indistinguishable from a genuine screenshot, and the missing chrome is a large part of why.
Using mock conversations responsibly
Fabricated chat images have an obvious dark side, and a tool that produces them should say so rather than pretend otherwise. A mockup presented as a real exchange is a fabrication, and depending on what it claims and who it targets it can be defamation, fraud, harassment, or evidence tampering. None of those stop being true because the image was easy to make.
The line is about presentation rather than the image itself. Using a mock conversation to illustrate a design, teach a concept, script a demo, or show a support flow is completely ordinary work. Using one to suggest that a specific real person said something they did not is not, and no framing makes that acceptable.
Practical guidance follows from that. Use obviously fictional names in anything that will be seen outside your team, label the image as a mockup where the context is not already clear, and do not reproduce a real person name, photograph, or handle in a fabricated exchange. If you are illustrating a real conversation you were part of, a genuine screenshot with the other party consent is the honest option.
- Fine: design mockups, documentation, teaching, demos, illustrations
- Not fine: presenting a fabricated exchange as something a real person said
- Use fictional names and label the image as a mockup when context is thin