Free Mobile App Layout Grid Generator
Lay out mobile screens instantly with our 100% free mobile app layout grid generator. Choose iOS and Android device frames with a column grid and safe-zone insets drawn where the status bar and gesture areas actually sit, then export SVG or 600 DPI in seconds. No signup, no downloads needed. Trusted by 60,000+ artists worldwide.
Safe areas, margins and a column field
A device-proportioned frame with its safe areas marked, the margins that keep content clear of the edges, and a column field to lay interface elements on.
9 controls, not a fixed picture
Set columns, margin, gutter and baseline rhythm (0 = off), choose orientation, toggle safe areas, standard bars, minimum tap target and measurements. Every one is live on the canvas.
Stacks with layout & design
Overlays combine, each carrying its own transform, so this one can sit under or over modular grid, baseline grid and modulor, and 11 more in the same set.
At device pixel sizes
Export at 1x, 2x or 3x so the guides land on real device pixels, or take SVG into a design tool as artboard guides.
| Ctrl + Z | Undo |
| Ctrl + Y | Redo |
| Esc | Deselect overlay |
| Alt + drag | Free positioning (no snap) |
| Ctrl + scroll | Zoom canvas |
| Ctrl + P | |
| ? | Show this help |
Two device proportions with the system chrome marked — because the interesting constraint in app layout is not where the columns are, it is which strips of the screen belong to the operating system.
The mobile app layout grid draws one of the 82 composition overlays in Grid Maker Pro, and the rest stack on the same image.
- 19.5:9 iOS
- 20:9 Android
- SVG + 600 DPI export
- Nothing uploaded
What is a mobile app layout grid?
The mobile app layout grid is a free browser tool that draws any of twenty-eight real device screens at its true proportions, with the safe-area insets that device reports. It covers every iPhone and iPad canvas plus the Android and Material window classes, in portrait or landscape. It adds a column grid whose margin and gutter are set in points, draws the cutout and home indicator that cause the insets, and prints the column measure in the device's own units. It draws over your own screen design, exports SVG and raster to 600 DPI, and never uploads anything.
How to use the mobile app layout grid
A device preset, its columns and its margins, on a blank artboard — so the layout is designed against the phone's real dimensions rather than a rounded version of them.
Pick the device
Twenty-eight canvases, grouped by family: the Dynamic Island iPhones, the notched ones, the Touch ID ones, the iPads, and the Android and Material window classes. Two phones that share a canvas share an entry, because they are one layout problem — an iPhone 16, a 15 Pro, a 15 and a 14 Pro are all 393 × 852 points.
JPG · PNG · GIF · WEBP
Set the columns and margin
Four columns is the phone convention and eight or twelve is the tablet one. The margin and the gutter are in points on iOS and density-independent pixels on Android — the units a developer is handed — and both are measured from the safe edge, so a landscape layout starts inside the sensor housing rather than under it. The overlay prints the column measure it arrives at.
Orientation · Columns · Margin
Read the insets, then export
The rules across the frame are that device's own safe-area insets, and the shapes at the top and bottom are what causes them. Turn on the standard bars and the minimum tap target to see what is left. Export SVG or a raster up to 600 DPI.
PNG · JPG · PDF · SVG · up to 600 DPI
Three steps, about a minute. No signup, no upload.
What the Mobile App Layout Grid does
Twenty-eight device canvases
Every iPhone screen from the 320 × 568 SE to the 440 × 956 Pro Max, the six iPad canvases, and the Android sizes the ecosystem clusters on. They are listed by canvas rather than by model name, so an iPhone 16, 15 Pro, 15 and 14 Pro are one entry at 393 × 852 — they are one layout problem, and naming them separately would only hide that.
Columns, 1 to 12
Four is the phone convention because a phone is too narrow for more and because four supports halves and quarters. Eight and twelve are the tablet counts. The margin and gutter are set in points rather than as a percentage, which is the unit both platforms specify in and the only one that means the same thing on a phone and on an iPad.
Insets, per device
The insets are each screen's own published values. An iPhone 16 reserves 59 points at the top for the Dynamic Island and 34 at the bottom for the home indicator; an iPhone SE reserves 20 and nothing, because it has a home button and no indicator to keep clear of. A percentage of the frame cannot say either of those things.
A rectangle you can trust
The dashed rectangle is the intersection of the horizontal margin and the vertical insets — the region where content is guaranteed visible and tappable on the chosen platform.
Centred on any canvas
The device frame is drawn at its true proportions and centred with a margin, so you can work on a landscape artboard, a square one, or a page, and still be designing at the right shape.
Over your own screen
Drop in a screenshot and check whether anything important is sitting under the status bar or behind the home indicator. That is the failure this grid exists to catch.
Mobile app layout grid examples: four ways the mobile grid reads
Mobile app layout grid vs a device frame mockup kit vs a simulator or real device
| Option | Safe insets drawn | Devices | Vector export | Cost |
|---|---|---|---|---|
| Grid Maker Prothis tool | Top and bottom, per device | 28 iOS + Android canvases | SVG + raster to 600 DPI | Free |
| A device frame mockup kit | Sometimes | A handful | Yes | Free to paid |
| A simulator or real device | Actual, exact | One at a time | No | Time |
| Design tool layout grids | Columns only | Whatever you draw | Yes | Subscription |
Who a mobile app layout grid is for: screens the system shares
How a mobile app layout grid works — Mobile layout: the columns are easy, the insets are the problem
App layout grids get discussed as though the interesting question were how many columns, which makes this the one of the 82 composition overlays whose real subject is the space you are not allowed to use. It is not. The interesting question is which parts of the screen the operating system has already taken, and that answer changes per platform and per device.
Start with the frame, because everything else is measured inside it. This overlay draws twenty-eight of them: every iPhone and iPad canvas Apple currently supports, and the Android sizes the ecosystem clusters on.
They are listed by canvas rather than by model, and that is the useful way round. An iPhone 16, a 15 Pro, a 15 and a 14 Pro are four phones with different cameras, different chips and one screen: 393 × 852 points. For a layout they are the same problem, and a list that named them separately would be four times as long while saying less.
The difference is small — about 2.6% — and it is enough to matter for anything anchored to both edges. A layout tuned so that a fixed element sits exactly at the bottom of an iOS frame will be a little short on Android, and vice versa.
Which is the first argument against designing to one device and hoping. The right habit is to design in proportions and check at both, and having both frames a click apart is what makes that habit cheap.
The safe insets
The insets are where the real constraint lives, and they are what distinguishes mobile layout from any other kind. On a page, the whole page is yours. On a phone, the operating system permanently occupies strips at the top and bottom of the display.
At the top that is the status bar, and on any device with a notch or a Dynamic Island it is considerably more than a status bar. This overlay reserves what the device itself reports: 59 points on an iPhone 16, 62 on an iPhone 17 Pro, 47 on an iPhone 14, 20 on an iPhone SE, 24 dp on an Android phone.
At the bottom it is the home indicator on iOS or the gesture area on Android. That is 34 points on every Face ID iPhone, 20 on an iPad, 24 dp on Android — and zero on an iPhone SE, which has a home button and therefore nothing at the bottom of the screen to keep clear of.
Those are the values the platform reports, not a working approximation. That distinction is the whole reason this overlay was rebuilt: the earlier version reserved a fixed 7% of the frame height at the top and 4.5% at the bottom, which is 59 and 38 points on an 844-point screen where the real figures are 47 and 34, and which on an iPhone SE drew a bottom inset that does not exist. A percentage is a shape; a safe area is a measurement.
The failure a design file cannot show
What the working reservation is good for is catching the failure mode, which is specific and common: something important placed in a strip the system will cover. A heading tucked under the status bar, a button under the home indicator, a piece of text behind a notch.
That failure is invisible in a design file, because a design file has no status bar. It only appears on a device, usually late, and usually to someone who is not the designer.
Laying this grid over a screenshot or a comp is a thirty-second check for it, and it is the single most useful thing the overlay does.
Why the bottom inset is the harder constraint
The bottom inset has a second consequence that is easy to miss: it is not just a visual reservation, it is a touch one. The area over the home indicator swallows gestures, so a button placed there may render fine and simply not respond reliably.
That makes the bottom safe line a harder constraint than the top one. Content under the status bar is ugly; a control under the home indicator is broken.
Columns and margins
The column count is the part everyone discusses and the part with the least in it. Four is the phone convention, for two reasons: a phone is too narrow to support more, and four divides into halves and quarters, which covers nearly every layout a phone screen needs.
Eight and twelve are the tablet counts, and this overlay offers up to twelve so a tablet layout can be checked in the same tool. Beyond that the columns are narrower than any usable element and the grid stops constraining anything.
The margin and the gutter are set in points, which is what both platforms' guidelines are written in: 16 points is the standard iOS content margin and 16 dp the Material one, and 24 is a common more generous choice. Setting them as a percentage would mean the same control produced a 6-point margin on a phone and a 61-point margin on an iPad Pro.
Below about 12 points the content starts to feel pressed against the screen edge, which on a curved-edge device also means it is physically harder to touch. Above about 40 you are wasting a screen that was already small.
Designing at phone scale
There is a broader point about design at phone scale that the grid can only hint at. A phone screen is small enough that vertical space is the scarce resource, and most layout failures on mobile are about running out of height rather than width.
Which is why the safe insets matter proportionally more than they look. On an 844-point frame, 59 points at the top and 38 at the bottom removes about 11.5% of the vertical space before anything is designed.
The frame is drawn at true proportions and centred on whatever canvas you are working on, so a phone layout can be designed on a landscape artboard or a printed sheet without distorting. That matters for review documents, where a set of screens is often laid out on a page.
Handoff, and what this overlay does not claim
For handoff, the useful export is SVG, because the frame and the safe rectangles remain editable and can be dropped into a design file as a layer rather than reproduced by hand.
One thing the overlay deliberately does not do is claim platform-specific certainty. Safe-area values are published by both platforms, they change between OS versions, and the authoritative source is the platform's own documentation. This is a design aid, not a spec sheet.
For the platform-specific obstruction zones of social video — which are a different problem with different numbers and change without notice — the social safe-area overlay is the right tool rather than this one.
The grid draws over your own screen rather than exporting a fixed template because the check is against a real design. A blank device frame is a wireframe kit and those are plentiful; the same frame over your screenshot tells you whether anything is sitting where it should not.
The export sizes itself from the paper format and the DPI you choose rather than from your screen. SVG keeps the frame, the columns and the safe rectangles as separate editable elements. The mobile app layout overlay page lists the per-device numbers, beside the rest of the design template category. The column count itself belongs to the column grid tool, and the spacing inside a component to the 8pt grid generator.
Everything runs in your browser. Images you load are never uploaded, because there is no server for them to reach. The drawing, the transform and the export all happen on your own machine.
Where a mobile app layout grid gets used
Content under the status bar is ugly. A control under the home indicator is broken — the gesture area swallows the touch.
The two frames differ by 2.6%. Small enough to look identical, big enough to break anything anchored to both edges.
Vertical space is the scarce resource. The insets take 11.5% of it before you have designed anything.
Mobile app layout grid: frequently asked questions
The geometry
Which devices can it draw?
Twenty-eight canvases. Every iPhone screen from the 320 × 568 first-generation SE to the 440 × 956 Pro Max, six iPad sizes, five Android phone canvases and the Material medium and expanded window classes. They are grouped by family in the Device list and named by the phones that share them, because two phones with the same logical screen are one layout problem.
Does the difference between two similar canvases matter?
For anything anchored to both edges, yes. A 390 × 844 iPhone is 19.49:9 and a 360 × 800 Android is exactly 20:9, and a layout tuned so a fixed element sits at the bottom of one comes up short on the other. The habit that survives it is to design in proportions and check against both, which is what switching the Device control does without moving anything else.
What are the safe insets?
The strips the operating system permanently occupies. At the top, the status bar plus any notch or Dynamic Island; at the bottom, the home indicator on iOS or the gesture area on Android. This overlay draws each device's own reported values rather than a fraction of the frame — 59 and 34 points on an iPhone 16, 20 and 0 on an iPhone SE.
Are the insets exact?
The logical screen sizes and the safe-area insets are the values the platform itself reports, so they are exact. Two things beside them are not: the display corner radius is a measured figure rather than a published one, and it is decorative here — nothing in the grid is derived from it — and the notch outlines are drawn to show where the top inset comes from rather than to be traced as a hardware mask. The insets, which are the load-bearing numbers, are the real ones.
What failure does this actually catch?
Something important sits in a strip the system covers — a heading under the status bar, a button under the home indicator, text behind a notch. That failure is invisible in a design file, because a design file has no status bar, and it usually appears on a device late.
Why four columns?
Because a phone is too narrow to support more, and four divides into halves and quarters, which covers nearly every layout a phone screen needs. Eight is the tablet count and twelve is available for a wide tablet or a Material expanded window; beyond that the columns are narrower than any usable element.
What margin should I use?
Sixteen points is the standard iOS content margin and 16 dp the Material one; 20 to 24 reads as more generous and is what this overlay opens on. Below about 12 the content feels pressed against the edge and is physically harder to touch on a curved-edge device; above about 40 you are wasting a small screen. The margin is measured from the safe edge, so in landscape it starts inside the sensor housing rather than under it.
Does it cover social video safe zones?
No. Those are a different problem with different numbers that change without notice — the social safe-area overlay handles them. This one covers operating-system chrome, which is comparatively stable.
Using it
How do I check a screenshot of a real app against it?
Load the screenshot, choose the matching device preset, and scale the overlay to the screen edges rather than the image edges. Most screenshots carry a status bar or a browser frame. Then look at whether the content respects the dashed safe insets.
What margin should I set?
Match whatever your design system already uses: commonly 16 points on both platforms, or 20 to 24 for a more generous feel. The value matters much less than using the same one everywhere, which is what the overlay makes visible across several screens at once — and because it is set in points rather than as a percentage, the same number means the same distance on a phone and on an iPad.
Export and print
Can I export a frame to design into?
Export the grid alone as SVG and place it in Figma or Sketch as a locked layer — you get the device proportion, the columns and the safe zones without a decorative device mockup around them, which is what you want while designing rather than while presenting.
What do I use for a design review deck?
The composite as a raster: the screen with the safe zones drawn on it. The point of the review is usually that something sits under the home indicator or behind the notch, and that argument needs both the design and the inset in one image.
Choosing a grid
Is the bottom inset different from the top?
It is a harder constraint, and on some devices it is not there at all. The area over the home indicator swallows gestures, so a control placed in it may render perfectly and simply not respond reliably — content under the status bar is ugly, a control under the home indicator is broken. On a Touch ID iPhone the bottom inset is zero, which is why the overlay draws no indicator there rather than reserving a band that does not exist.
Should I use this or an 8pt spacing grid?
Both, for different failures. This catches content colliding with system chrome and columns not agreeing; the 8pt grid generator catches spacing that is not on the step. A screen can pass one and fail the other.
Practical matters
Does anything I load get uploaded?
No. There is no server to upload to. The image is read by your browser, the grid is drawn on your machine, and the export is generated locally.
Does it handle landscape?
Yes, and the landscape insets are not the portrait ones turned on their side. A Face ID iPhone in landscape reports no top inset at all, 21 points at the bottom instead of 34, and 59 points on BOTH long edges — it insets each side so a layout is symmetric however the phone was turned. A Touch ID iPhone hides its status bar in landscape and reports nothing on any edge. An iPad keeps its status bar either way. The Orientation control draws each of those correctly.
Open the tool Mobile app layout grid
The screen, minus the system's share
A mobile app layout grid draws two device shapes with their insets marked and the columns adjustable. Export vector or 600 DPI. No signup, nothing uploaded.
Back to the generator →