How to Take Responsive Website Screenshots at iPhone 13 and iPhone 14 Sizes

The standard iPhone 13 and iPhone 14 use the same portrait viewport: 390 × 844 points. For a responsive layout preview, set that viewport in Safari Responsive Design Mode on a Mac. If you need to check Apple-platform behavior, use Simulator; if you need an authentic device screenshot or a bug depends on real hardware, use an actual iPhone.

At a 3× pixel ratio, 390 × 844 points corresponds to 1170 × 2532 pixels. The standard iPhone 13 and iPhone 14 share these dimensions. The iPhone 13 mini is smaller, at 360 × 780 points.

1. Choose the screenshot you need

First decide whether you need the visible viewport or the entire page:

Viewport screenshot: captures what fits in the 390 × 844-point portrait viewport. Use this for responsive layout checks and above-the-fold previews.
Full-page screenshot: captures page content beyond the visible screen. This is a different deliverable; a full-page image may be much taller than the phone’s screen.

Also decide how much device fidelity the task needs. A desktop preview is quick for checking breakpoints. Simulator can expose more Apple-platform behavior. A physical iPhone is the right choice for actual-device conditions, such as touch interactions, browser chrome, or keyboard behavior.

2. Quick responsive preview in Safari on a Mac

Open the page in Safari on macOS.
If the Develop menu or developer tools are not visible, enable Safari’s developer features in Safari settings. The precise settings labels can vary by macOS and Safari version.
Choose Develop > Enter Responsive Design Mode.
Set a custom viewport to 390 × 844 points in portrait. If the controls offer a pixel-ratio setting and you need a device-density preview, choose 3×.
Inspect the page and capture the visible preview using the screenshot controls available in your Safari version.
Check other viewport sizes or rotate to landscape separately if you are testing breakpoints or orientation changes.

Responsive Design Mode can vary the viewport and pixel ratio to help test media queries and dynamic styles. A desktop preview remains an approximation: it does not guarantee the same rendering and behavior as a physical iPhone. Presets and dimensions do not reproduce every browser, operating-system, keyboard, or device condition.

If the issue depends on Apple-platform behavior, Safari’s Responsive Design Mode may offer an option to open the page in Simulator. The menu layout and available options depend on the installed versions.

3. Use Simulator for Apple-platform behavior

Use an iOS Simulator runtime when you want a closer look at how a page behaves in Apple’s software environment without using a physical phone. Xcode includes Simulator, but the required runtimes and UI options depend on the Xcode installation.

Install or open Xcode and make an iOS simulator runtime available.
Open the page in Safari’s Responsive Design Mode and use its Simulator option if available, or open the relevant device in Simulator and launch Safari there.
Inspect the page at the intended device size and capture the view using the available screenshot controls.

Simulator can help expose behaviors such as rendered text size, viewport meta tag effects, double-tap zoom, and Home Screen web app behavior. It is still a software test environment; it does not prove that the page was tested on a physical iPhone.

4. Inspect and capture on a physical iPhone

Use an actual iPhone 13 or iPhone 14 when the result must reflect real-device behavior or be an authentic on-device screenshot. To inspect iPhone Safari from a Mac:

On the iPhone, enable Settings > Apps > Safari > Advanced > Web Inspector. The exact path can vary with iOS version.
Connect the iPhone to the Mac and trust the computer when prompted.
Open the page in Safari on the iPhone. In Mac Safari, use the Develop menu to select the connected device and its page.
For later inspection over the network, Apple describes enabling network connection after the initial cable connection.
Capture on the iPhone itself when the screenshot needs to be an authentic device capture.

Remote Web Inspector is useful for examining a real page while it runs on the phone. If the required artifact is simply the phone’s screenshot, use the iPhone’s screenshot controls.

5. Capture a full webpage on iPhone

Safari on iPhone supports capturing content that extends beyond the display, including an entire webpage. That output is not the same as a screenshot of the visible 390 × 844-point viewport. The capture controls vary with iOS version and content, so follow the screenshot interface presented on the device and select the full-page option when it is available.

Use a viewport capture when you need to document what a user sees at one scroll position. Use a full-page capture when you need a long-page overview. If you need a full-page image at a controlled viewport across many URLs, use an automated browser or screenshot API and verify how it handles lazy-loaded content.

6. Dimensions and settings at a glance

Device or setting	Value	Use
Standard iPhone 13 portrait	390 × 844 points	Responsive viewport size
Standard iPhone 14 portrait	390 × 844 points	Same baseline viewport as standard iPhone 13
3× raster equivalent	1170 × 2532 pixels	Approximate native-density output when pixel ratio is configurable
iPhone 13 mini portrait	360 × 780 points	Use this if the target is specifically the mini model

Matching the viewport does not make the iPhone 13 and 14 identical in every respect. Browser chrome, iOS version, keyboard state, and device-specific behavior can affect the visible page. A viewport size is a useful layout baseline, not a substitute for checking the behavior relevant to your task.

7. Which workflow should you use?

Workflow	Best for	Trade-off
Safari Responsive Design Mode	Fast layout and breakpoint checks at a custom viewport and pixel ratio	Approximate rendering and behavior
Xcode Simulator	Apple-platform behavior without a physical phone	Requires Xcode and a simulator runtime; still not a physical-device test
Physical iPhone	Real-device behavior and authentic device screenshots	Requires access to the phone; remote inspection from Mac requires setup

8. Common problems and fixes

Problem	Likely cause	What to do
The page does not match the expected iPhone layout	The viewport is not 390 × 844 points, or the site has a separate breakpoint	Set the custom portrait viewport explicitly, then inspect the site’s responsive breakpoints and viewport meta tag.
The screenshot pixel dimensions look too small	The preview is at 1× or another pixel ratio	Set 3× when the tool supports it and the goal is device-density output. The viewport remains 390 × 844 points.
A desktop preview differs from the iPhone	Responsive emulation does not reproduce every iOS, browser chrome, keyboard, or hardware behavior	Use Simulator for Apple-platform behavior or reproduce the issue on a physical phone.
The Develop menu or Responsive Design Mode is missing	Safari developer features are not enabled, or the UI differs by version	Enable developer features in Safari settings and consult the menus available in that installed version.
The iPhone does not appear in Mac Safari’s Develop menu	Web Inspector is off, the phone has not trusted the Mac, or the connection is not established	Enable Web Inspector, reconnect and trust the Mac, then reopen the page in iPhone Safari.
The full-page capture is not 390 × 844 pixels	A full-page screenshot includes content beyond the visible viewport	Choose a viewport capture for screen-sized output; choose full-page only when a tall page image is intended.
Content is missing near the bottom of a full-page capture	Some page content loads lazily as it approaches the viewport	Scroll through the page before capture or use a capture workflow that loads lazy content, then check the output.

9. Performance, reliability, and cost

For a single breakpoint check, Safari Responsive Design Mode is usually the shortest setup because it runs in the browser already on your Mac. Simulator adds setup time for Xcode and its runtime. Physical-device inspection takes longer to connect, but it is the most relevant option when the bug depends on real-device conditions.

For repeatable captures across many URLs or scheduled runs, automate the browser or use a screenshot API. Keep the viewport and pixel ratio explicit, set a sensible navigation timeout, and distinguish failed loads from valid screenshots. Dynamic pages may need a wait condition, and long pages may need lazy content loaded before capture. These choices affect completion time and consistency.

The manual Safari, Simulator, and iPhone workflows use software and hardware you already have access to; no new phone or accessory is required for the basic method. Automated screenshot services may charge by use or plan, so check their billing rules and how they treat failed loads and cached results before running large batches.

10. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Send one GET request with the URL and the 390 × 844 viewport settings to receive a screenshot. Check the ScreenshotNeo API documentation for the current parameter names and response details.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -d width=390 \
  -d height=844 \
  -d device_scale_factor=3 \
  -d format=png \
  -o iphone-13-14.png

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={
        "access_key": "YOUR_API_KEY",
        "url": "https://example.com",
        "width": 390,
        "height": 844,
        "device_scale_factor": 3,
        "format": "png",
    },
    timeout=90,
)
r.raise_for_status()
with open("iphone-13-14.png", "wb") as image:
    image.write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com',
  width: '390',
  height: '844',
  device_scale_factor: '3',
  format: 'png',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('iphone-13-14.png', image));

Replace https://example.com with the page you need to capture. Parameter names used by other screenshot APIs also work with ScreenshotNeo; refer to the docs for the accepted names and format options. A 390 × 844 capture is a responsive screenshot at the matching viewport; it does not reproduce all behavior of a physical iPhone.

ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and whether the request was billed. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots each month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

Frequently asked questions

Are iPhone 13 and iPhone 14 website sizes different?

The standard models share a 390 × 844-point portrait baseline. Other device and software behavior can still differ.

Should I set the screenshot to 390 × 844 pixels?

No. That is the viewport in points. At 3×, its raster equivalent is 1170 × 2532 pixels.

Does Responsive Design Mode prove the site works on an iPhone?

No. It is useful for responsive layout checks, but Apple cautions that previews approximate actual-device rendering and behavior. Use Simulator or a physical phone when fidelity matters.

Can I use the same size for a full-page screenshot?

Use 390 × 844 as the viewport. A full-page capture extends beyond that viewport and produces a taller image.