How to Test a Responsive Website Screenshot at 768-Pixel Tablet Width

To test a responsive website screenshot at 768-pixel tablet width, set the browser viewport to exactly 768 CSS pixels, inspect the layout and nearby breakpoints, then capture either the visible viewport or the full page. In Chrome, use DevTools Device Mode for a quick manual check. Use Playwright when you need a repeatable screenshot. A 768-pixel viewport is a useful layout target, not a guarantee that every tablet will render identically.

1. Set up a 768-pixel viewport in Chrome DevTools

Open the page in Chrome and open DevTools. Turn on the device toolbar. Device Mode opens in responsive mode by default.
In the width field, enter 768. Chrome also provides a 768-pixel Tablet preset; entering the width directly makes the target explicit.
Choose a height that shows the content you want to inspect. Width alone does not determine how much of the page appears in a viewport screenshot. Record the height too if you need to compare captures later.
Inspect the page at 768 pixels. Check navigation, columns, text wrapping, image sizes, spacing, and whether controls remain usable.
Open the Device Mode More options menu and enable Show media queries. Inspect the breakpoint bars and check the page around relevant breakpoints as well as at exactly 768 pixels.
For the visible area, choose Capture screenshot from the More options menu. For all scrollable content, choose Capture a full size screenshot.

Chrome lists 768 pixels as a Tablet preset alongside 320, 375, 425, 1024, 1440, and 2560 pixels. The label is a convenient preset; it does not mean all tablets share the same viewport, pixel density, browser, or behavior. See Chrome DevTools Device Mode documentation.

2. Decide what the screenshot should prove

A screenshot is only useful for a specific test if its capture conditions are clear. Before comparing results, decide whether you are checking the first screen, the entire page, one component, a breakpoint transition, or high-density rendering.

Check	Capture choice	What to keep consistent
Initial layout and visible controls	Viewport screenshot	URL, viewport width and height, browser, scroll position
Content below the fold, page length, footer	Full-page screenshot	Page state, loaded content, viewport width
One card, menu, or form	Element screenshot in automation	Selector, page state, viewport
Breakpoint behavior	Captures at 768 and just below/above relevant breakpoint	Same browser and other settings
Retina or high-DPI appearance	Device-scale screenshot or device-pixel-ratio emulation	CSS viewport and device scale factor as separate values

The width in this guide means 768 CSS pixels, which is the width used by responsive CSS layout. A screenshot file can have more physical pixels when captured at a device scale above 1. For example, the CSS viewport can remain 768 pixels wide while the output image is twice as wide in device pixels. Do not change the CSS viewport just to make the screenshot file higher resolution.

3. Check the breakpoint, not just the target width

A page can look correct at 768 pixels while breaking a few pixels to either side. Use the media query indicators in DevTools to see where the site’s responsive rules apply, then inspect the active layout on both sides of the boundaries relevant to that page. There is no universal breakpoint that every site must use.

Look for horizontal scrolling, clipped content, overlapping navigation, and columns that become too narrow.
Check that text wraps without covering buttons, labels, or images.
Confirm images preserve their intended crop and aspect ratio and that the right responsive image is selected where applicable.
Check controls at normal zoom and make sure menus, dialogs, and forms fit within the available viewport.
Test both portrait-like and landscape-like heights if the page depends on vertical space. The title specifies width; height remains a separate test input.

Chrome DevTools’ breakpoint display helps you move between media-query boundaries. For a broader explanation of responsive layout checks, see web.dev’s responsive web design guide.

4. Automate repeatable screenshots with Playwright

For regression checks, configure the viewport explicitly and save a screenshot after the page reaches the state you want to compare. Playwright supports viewport configuration and screenshot capture; screenshot scale can be CSS pixels or device pixels. See the official emulation and screenshots documentation.

Node.js: runnable Playwright script

Install Playwright and its Chromium browser, then save this as capture-768.mjs. Replace the sample URL with your page.

npm install playwright
npx playwright install chromium

// capture-768.mjs
import { chromium } from 'playwright';

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage({
  viewport: { width: 768, height: 1024 },
  deviceScaleFactor: 1,
  isMobile: false,
});

try {
  await page.goto('https://example.com', {
    waitUntil: 'networkidle',
    timeout: 60000,
  });

  // Capture the visible viewport at 768 CSS pixels wide.
  await page.screenshot({ path: 'tablet-768-viewport.png', scale: 'css' });

  // Capture all scrollable page content at the same CSS viewport width.
  await page.screenshot({
    path: 'tablet-768-full.png',
    fullPage: true,
    scale: 'css',
  });
} finally {
  await browser.close();
}

networkidle is a convenient starting condition, but pages with continuous background requests may never become idle. In that case, wait for a specific page element or a deliberate short delay instead. If the page loads content only as you scroll, a full-page capture may need an explicit scroll-and-load step before the screenshot.

Python: runnable Playwright script

Install the Python package and browser, then save the script as capture_768.py.

python -m pip install playwright
playwright install chromium

# capture_768.py
import asyncio
from pathlib import Path
from playwright.async_api import async_playwright

async def main():
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        page = await browser.new_page(
            viewport={"width": 768, "height": 1024},
            device_scale_factor=1,
            is_mobile=False,
        )
        try:
            await page.goto(
                "https://example.com",
                wait_until="networkidle",
                timeout=60_000,
            )
            await page.screenshot(
                path="tablet-768-viewport.png",
                full_page=False,
                scale="css",
            )
            await page.screenshot(
                path="tablet-768-full.png",
                full_page=True,
                scale="css",
            )
        finally:
            await browser.close()

asyncio.run(main())

For a high-density output image, set device_scale_factor=2 and use scale="device". That changes output pixel dimensions, not the CSS viewport width. For stable visual regression results, keep the browser version, operating environment, fonts, viewport height, scale, and page state consistent between baseline and comparison runs. Playwright notes that rendering can vary across operating systems, browser versions, settings, and hardware; see its visual comparison guidance.

Useful Playwright options

Option	Use
`viewport: { width: 768, height: 1024 }`	Sets the CSS viewport dimensions. Choose and record a height for comparable viewport shots.
`deviceScaleFactor: 1` or `2`	Emulates pixel density in the browser context. Keep this distinct from CSS viewport width.
`fullPage: true`	Captures the full scrollable page rather than only the visible viewport.
`scale: 'css'`	Produces one image pixel per CSS pixel; useful for compact, consistent layout checks.
`scale: 'device'`	Produces an image at device-pixel scale for higher-resolution output.
`page.locator('.selector').screenshot(...)`	Captures one component when the test concerns a specific element.
`isMobile`, touch, user agent	Use when testing mobile-specific behavior; a 768-pixel viewport alone does not configure every device characteristic.

5. Validate in Safari or on a real device when needed

Browser emulation is effective for checking responsive layout, but it does not reproduce every physical-device detail. For Safari-specific review, use Safari Responsive Design Mode to set width, height, and pixel ratio. Apple notes that presets are approximations and that address-bar behavior, the on-screen keyboard, and device-specific form controls can affect the actual experience. Use an appropriate simulator or real device when those details matter. See Apple’s Responsive Design Mode documentation.

Prioritize an actual-device check when a bug depends on the browser chrome changing the usable area, keyboard appearance or dismissal, touch interaction, native form controls, or a particular Safari/iOS rendering behavior. For a general layout check at 768 CSS pixels, begin with DevTools or a scripted browser capture, then validate the device-specific concern separately.

6. Common problems and fixes

Problem	Likely cause	Fix
The page does not look like a tablet layout	The browser window was resized, but the emulated viewport width was not set to 768 CSS pixels.	Use Device Mode and verify the width field. In automation, set `viewport.width` to `768`.
The screenshot has unexpected dimensions	Device-pixel scaling or screenshot scale changed output dimensions.	Check CSS viewport width, device scale factor, and screenshot scale separately. Use CSS scale when you want one output pixel per CSS pixel.
The viewport screenshot misses the footer	A viewport capture includes only the currently visible area.	Use a full-page capture when you need all scrollable content. Record whether the capture is viewport or full-page.
Full-page screenshot omits lazy-loaded images	Images or other content load only after scrolling into view.	Scroll through the page before capture, wait for the relevant content, and then capture. Do not assume navigation completion means every lazy resource has loaded.
Automation hangs waiting for navigation	The page keeps network connections active, so network idle is never reached.	Wait for a meaningful selector with a timeout, or use a controlled delay when the page has no reliable readiness marker.
Captures differ between runs without a layout change	Dynamic content, animation, timestamps, fonts, browser versions, or differing page state changed.	Use the same environment and state, wait for fonts and key content, and disable or stabilize animations and volatile elements in the test setup.
CSS seems to ignore the intended tablet width	A viewport meta tag may be missing, or another layout rule may be controlling the result.	Inspect the page’s viewport configuration and active media queries. Confirm the CSS viewport in the browser before diagnosing the breakpoint.
Layout passes in emulation but breaks on a tablet	Browser chrome, keyboard, touch, native controls, or device-specific behavior differs.	Reproduce on the target browser/device or a suitable simulator and test the behavior that depends on it.

7. Reliability, performance, and cost

Manual DevTools checks are quick and do not require a screenshot service. They suit one-off inspection, breakpoint debugging, and captures for a bug report.
Playwright automation takes browser setup and maintenance, but makes the width, height, browser context, and capture steps explicit. Run it in a consistent environment for visual comparisons.
Full-page capture can take longer and create much taller files than viewport capture. Use it when below-the-fold content matters; use viewport shots for first-screen and viewport-specific checks.
Repeatability depends on more than width: hold URL state, cookies, fonts, browser version, color scheme, scale, and content state steady as needed.
Service cost depends on the capture method. Local DevTools and self-hosted Playwright do not incur a per-screenshot API charge, though browser infrastructure and maintenance still take resources.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request returns an image or PDF, and its options include viewport sizing and full-page capture. See the ScreenshotNeo API documentation for parameters and configuration.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -d width=768 \
  -o tablet-768.webp

With width=768, the request targets a 768-pixel viewport; set a height and full-page option as appropriate for the comparison. Cookie banners, popups, and chat widgets are removed before the shot, and each step can be turned off. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents use the take_screenshot, get_page_info, and capture_pdf tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

FAQ

Is 768 pixels the width of every tablet?

No. It is a useful CSS viewport target and a Chrome preset labeled Tablet. Actual tablet viewports and browser behavior vary, so test the widths relevant to your users.

Should I capture a full page or just the viewport?

Use a viewport capture to inspect the visible first screen at a chosen height. Use full-page capture to review content below the fold, while remembering that lazy-loaded content may need to be triggered first.

Does a 768-pixel screenshot have to be 768 image pixels wide?

No. CSS viewport width and image pixel dimensions are separate. Device-scale output can be wider than 768 physical pixels while preserving a 768 CSS-pixel layout.

Is browser emulation enough to validate a tablet release?

It is a good layout check. Add a simulator or real-device pass if the behavior under test depends on browser chrome, the software keyboard, touch, native controls, or a particular browser.