“Make a fake text message” means two completely different things depending on which side of the platform divide your audience is on. On iPhone, a text lives in iMessage: blue bubbles, no timestamps inside the bubbles, a small “Delivered” line underneath. On Android, it lives in Google Messages: Material-flavoured blue, timestamped bubbles, a different header entirely. Audiences notice instantly when the two are mixed, because both interfaces are among the most viewed screens in the world.
This guide covers both, using the free text message generator and the Android SMS generator — no signup, no watermark, everything rendered locally in your browser.
iPhone: the rules of an iMessage mockup
iMessage is deceptively minimal, which is exactly why errors stand out. Get these four details right and the screenshot passes a casual glance every time:
- Bubble colour: outgoing is the Apple blue, incoming is light grey. Never use WhatsApp green or a saturated default web blue — the Apple blue is softer than most people remember.
- No timestamps inside bubbles. Times appear as small centred dividers between groups of messages, not per-bubble.
- The delivery line. Under the last outgoing message sits a tiny grey “Delivered” label. It is one of the most-looked-at details in the whole screenshot — including it, with the right wording and weight, does more for realism than any other single element.
- Bubble shape and width. Fully rounded ends, and a width cap around three-quarters of the screen. A bubble that stretches edge to edge reads as fake before anyone reads a word.
Android: the rules of a Google Messages mockup
The Android SMS generator follows Google Messages, which behaves differently from iMessage in ways that are easy to get wrong:
- Bubbles carry their own timestamps. Unlike iMessage, the time sits inside the bubble next to the text, in a smaller, muted shade.
- Header shows the contact with a letter avatar. Google Messages uses a coloured circle with the contact's initial, not a photo by default.
- The blue is different. Google's Material blue is closer to a classic link blue than Apple's pastel-leaning bubble. Reusing the iMessage blue on an Android frame is a dead giveaway.
- Status bar geometry. Android shows the clock on the left and the battery/signal cluster on the right, and no camera cutout at all — the reason our exports skip the phone frame by default: a real screenshot is captured by the OS and never contains the body of the phone.
Choosing the right platform for your scene
Match the device to the character, not to your own phone. A teenager in the US is believably on iMessage; a small-business owner in Europe or Asia is more likely on WhatsApp or Telegram; an Android flagship user in almost any market is on Google Messages or a manufacturer's SMS app. If your video or slide deck shows an iPhone frame around Google Messages colours, the audience will not be able to name the error, but they will feel it — and that faint wrongness costs you immersion.
A practical trick from storyboard artists: decide the platform first, then let it shape the dialogue. iMessage's “Delivered” line is a storytelling tool — a message marked delivered but never answered says “being ignored” without a single word of dialogue. On Android, the visible in-bubble timestamps let you show a three-hour gap between messages as pure visual information.
Typing rhythm: the part no generator can do for you
The screenshots that convince are the ones where the conversation has rhythm. Real texting is lopsided — one person sends four messages while the other sends one. Typos happen and usually stay uncorrected. Punctuation fades in casual chats and returns in awkward ones. And the most natural pattern of all is the double text: two short messages in a row from the same sender, the second one walking back the first. If every exchange in your mockup is a tidy question and a tidy answer, it reads as written correspondence, not a conversation.
Exporting for video and slides
Both generators export PNG at 1x, 2x and 3x. For video overlays and slide decks, 2x is the sweet spot: sharp on a retina screen without bloating file size. For a phone-in-hand shot in a video, turn the phone frame on; for a full-screen insert where you will add your own motion and shadows, turn it off and export just the screen. And as always, everything is generated on your device — no account, no upload, no watermark.
iPhone and Android, item by item
The two interfaces diverge in a handful of specific places, and once you can see them side by side it becomes easy to tell which platform a screenshot was built for. Here is the comparison the two generators implement, detail by detail.
| Detail | iPhone (iMessage) | Android (Google Messages) |
|---|---|---|
| Header | Contact name centred under a small round avatar, with a blue video-call icon on the right | A blue letter-avatar circle beside the name, with a subtitle line and phone and video icons |
| Outgoing colour | Apple blue, softer and slightly pastel | Google blue #1a73e8, the same blue in both modes |
| Bubble radius | 18px, fully rounded capsules | 20px Material capsules |
| Last bubble in a run | A bottom corner tucks in to about 5px, marking the end of a burst | The sender-side corner squares to about 6px |
| Bubble width cap | About 72% of the column | About 75% of the column |
| Where the time sits | One centred “iMessage” and date line at the very top, and nothing inside the bubbles | A centred date marker at the top; a per-message clock varies between Android messaging clients and OS versions, so the safe default is to leave it out |
| Delivery marker | A small grey Delivered or Read line under the last outgoing message | A small grey Read label under the last outgoing message |
| Status bar | iPhone arrangement — and because a real screenshot never captures hardware, no camera cutout appears | Clock on the left, signal and battery on the right, no camera cutout |
Read as a set, the differences are small but they compound. A screenshot with iMessage's pastel blue, an 18px radius and a single top date line is unmistakably iPhone; swap in Google blue, a 20px capsule and the Android header shape and you are on Google Messages. Mixing the two — Apple's blue on an Android frame, or an Android letter avatar over an iMessage layout — is what makes a mockup feel wrong to a viewer who cannot say why.
RCS versus SMS: what actually changes in a screenshot
The read receipt is the one place the underlying protocol shows up on screen, and it is worth understanding because it decides whether a label is even plausible. Older SMS is a plain store-and-forward service: your message reaches the recipient and the network reports delivery at best, but there is no signal back to your screen that a person opened it. RCS, the newer standard Google Messages uses, can carry read receipts — but only when both parties are on capable phones and carriers and the feature is enabled, which is why “it depends” is the honest answer.
For a mockup that means a simple rule. If you are staging a plain-SMS scene, ending the thread on your own bubble with a Read label invites a close look at something the protocol may not support — a Delivered-style marker, or no marker at all, stays plausible. If you intend the thread to be an RCS conversation between two modern Android phones, the small grey Read label is exactly right, and leaving it off is equally valid because read receipts can simply be turned off.
The same logic applies to typing indicators and higher-resolution media: they belong to the richer protocol, so a screenshot that shows them is implicitly claiming an RCS conversation. None of this is visible in most viewers' day-to-day use, which is precisely why getting it right marks a mockup as thoughtful rather than approximate. For a complete Android scene, the Android SMS generator already renders the Read label the RCS way, and the Android screenshot guide walks through the rest of the frame.
Use it as a prop, not as proof
A staged text conversation used in a skit, a design review or a classroom exercise is a legitimate creative device. The same image used to manufacture evidence, to impersonate someone, or to deceive a specific person is not, and our Acceptable Use Policy draws that line explicitly. Make things audiences recognise as staged — the good kind of fake is the one nobody is ever tempted to submit as proof.