Most text-message mockups on the internet are iPhone mockups. Search for any guide and you will find iMessage blue, a rounded iPhone header, a centred clock — and it is genuinely a problem, because the majority of phones in the world run Android. A convincing Android screenshot is not an iPhone screenshot recoloured. Google Messages has its own Material Design language, its own status bar, its own way of confirming that a message was read, and its own bubble geometry. Borrow any of the iPhone conventions and the result looks like an Android phone pretending to be an iPhone, which is a very specific kind of wrong.
This guide covers how to build a Google Messages screenshot that holds up, using the free Android SMS generator. It runs entirely in the browser and exports a high-resolution PNG.
Android is not a recoloured iPhone
The instinct when building an Android mockup is to take everything you know about iMessage and swap blue for blue. That gets you a screenshot with the right general feel and half a dozen small errors, and the errors are the ones Android users spot first. The two interfaces differ at every level: bubble radius, bubble grouping, read confirmation, status bar, and header structure.
Google Messages is Material Design, and Material has a recognisable softness — large corner radii, generous padding, a clean rectangular surface. iMessage is tighter, tail-driven and more compact. Once you internalise that the two come from different design traditions, the individual differences stop feeling arbitrary and start looking like a system you can follow.
The values the real app uses
These are the values the generator bakes in, taken from the real client. If you are rebuilding the interface by hand, start here.
| Element | Light mode | Dark mode |
|---|---|---|
| Chat background | #ffffff | #1f1f1f |
| Outgoing bubble | #1a73e8 — Google blue, white text, in both modes | |
| Incoming bubble | #f1f3f4 | #303134 |
| Bubble shape | 20px capsules; the last bubble in a run narrows to 6px on the sender's side | |
| Read confirmation | Small grey Read under the last outgoing message | |
| Status bar | Android style: clock on the left, signal and battery on the right, no camera cutout | |
Two numbers here are worth committing to memory because they are the most frequently botched. The outgoing blue is #1a73e8 — noticeably deeper and cooler than iMessage's lighter blue — and it does not change between light and dark mode. The bubble radius is 20px, larger than iMessage's, which is what gives the Material bubbles their soft capsule look.
Read is text, not ticks
This is the detail that trips up the most Android mockups. Google Messages does not use a tick system. There are no grey ticks, no double ticks, no blue ticks anywhere on the screen. Under RCS, the app confirms delivery with a small grey Read label beneath the last outgoing message — plain text, not a symbol.
A mockup with blue double-checks is borrowing WhatsApp or iMessage, and it is wrong for Android in a way that any daily user registers immediately. The label is editable in the generator: write Read with a time, keep it as just Delivered, or clear it for a message that has not been seen yet. As with Messenger's Seen line, leaving it off is a scene decision — it means the recipient has not read the message, which is a specific and useful state.
The status bar tells
There is a clean structural difference between the two mobile worlds that shows up in every screenshot: the status bar. On Android it is a plain rectangle with the clock on the left and the signal and battery icons on the right. There is no camera cutout, no notch, no dynamic island — because a real screenshot captures the display, not the hardware hole punched into it.
The generator renders the Android layout by default: clock left, icons right, no cutout. That last point is a common failure in hand-built mockups, where a designer copies an iPhone silhouette and leaves a notch visible in an Android screenshot. It is a small detail that immediately signals the screen was assembled from the wrong template.
The related decision is the phone frame. It is off by default on this page, and that default is correct: an Android interface inside an iPhone shell looks wrong, and a real screenshot never includes the phone body in the first place. Turn the frame on only when you specifically want a device-mockup look for a thumbnail or slide, and if you do, make sure the shell is Android-shaped.
From an empty editor to a finished screenshot
- Choose the contact. Type a name into Contact → Name and upload an avatar. Without one, the generator draws a blue initial circle, the way Google Messages renders contacts without photos.
- Type the thread. Android messaging reads as short bursts, so keep most rows to a line or two and let the reply land in the final bubble. Any row can carry an image, and it renders as a rounded media bubble above the caption text.
- Set the Read label. Under Contact → Delivery the label defaults to
Read, shown under your last outgoing message the way RCS confirms it. Clear it for a message that has not been seen. - Group your runs. Let two or three messages come from the same sender before the reply. The generator tightens the connecting corners to 6px automatically, but it needs runs to work with.
- Export. Pick 1x, 2x or 3x and download the PNG. The phone frame starts off — an Android interface in an iPhone shell would look wrong — but you can enable it if your composition needs one.
The tells that give a fake Google Messages screenshot away
- Blue double-check ticks. Google Messages confirms with a text
Readlabel, never a tick. - An iPhone status bar: a centred or right-aligned clock, a notch, or a camera cutout. Android puts the clock on the left with no cutout.
- iMessage's lighter blue instead of Google blue
#1a73e8. - 18px bubbles. Material capsules are 20px, with the sender-side corner narrowing to 6px at the end of a run.
- A
Deliveredlabel standing in forReadon an RCS-style thread. - Bubble tails, and a phone frame shaped like an iPhone.
- A grey or coloured header bar. The Google Messages header is a clean surface with the contact name and a letter avatar.
Trade-offs: Samsung Messages, RCS versus SMS, and the frame
The first trade-off is which Android app you are imitating. Google Messages is the stock SMS and RCS app on most Android phones, and it is what this generator reproduces. Samsung's own Messages app is a different layout with different geometry, and it is not covered here — so if your scene is set on a Samsung device, be aware the screen you build is Google's, not Samsung's. Mixing the two is a small but real inconsistency.
The second trade-off is RCS versus SMS. The Read label belongs to RCS, the richer messaging standard where delivery and read states are real. Pure SMS does not reliably return that information, so a plain SMS thread showing Read is slightly optimistic — though it reads as believable to most audiences, and if your scene needs the read state, RCS is the honest framing.
The third is the phone frame, already covered above: off by default, worth turning on only for composed layouts, and never an iPhone shell around an Android screen. Getting the frame wrong undoes an otherwise accurate mockup, because the shell is the first thing the eye sees.
If your scene is set on an iPhone instead, the iPhone text message generator covers iMessage with its own bubble geometry and Delivered line. The two interfaces are not interchangeable, and the comparison of text messaging on iPhone and Android walks through the differences side by side.
Staying on the right side of the line
SMS screenshots show up in stories where the delivery channel is the point: a text that lands at the worst possible moment, a one-time code, a message from an unknown number. Tutorials and security-awareness material use them constantly, because SMS is the one interface every phone owner recognises regardless of platform, and with Android holding the majority of global phone share, an iOS-only mockup collection misses much of the audience. All of that is legitimate creative and educational work. Fabricating a message to deceive someone, harass a person, impersonate a company or institution, or create false evidence is not, and the message channel makes no difference to that. The Acceptable Use Policy has the full boundary, and there are no templates here for fake bank, government, medical or legal notices. To see finished Android scenes before you build your own, the Android examples gallery renders them live.