WordPress 7.1 responsive breakpoints let you test and adjust layouts for Mobile, Tablet, and Default directly in the WordPress editor. With a compatible block theme, you can change font size, spacing, width, color, borders, and some layout properties in the Site Editor, rather than writing custom CSS for each screen size (according to wordpress.org)
However, two separate tasks need to be distinguished: administrators can use the interface to test responsive styles, while defining new breakpoints precisely in theme.json is generally the responsibility of the theme author or someone with permission to edit theme files. This article presents a practical process for testing mobile layouts, identifying issues, and making adjustments within the limits supported by WordPress 7.1.
How do WordPress 7.1 responsive breakpoints work?
WordPress 7.1 provides viewport states for applying different style values to the same block. By default, Mobile applies to screens up to 480px wide, Tablet applies to screens wider than 480px and up to 782px, while Default is the base value applied at all sizes when no separate override is defined (according to developer.wordpress.org).
| State | Default screen range | How to interpret it when editing | Suitable example |
|---|---|---|---|
| Default | All sizes | Base and fallback value | Heading font size: 48px |
| Tablet | More than 480px up to 782px | Override only within the Tablet range | Reduce the block’s padding |
| Mobile | Up to 480px | Override only within the Mobile range | Reduce the heading to 32px |
A common source of confusion is that Tablet and Mobile do not inherit from each other. If you set a separate font size for Tablet but not for Mobile, Mobile falls back to the Default value rather than automatically using the Tablet value. Therefore, when you want a consistent design on smaller screens, check both states.
A theme can change these default values in theme.json. Therefore, 480px and 782px are reference points, not a guarantee that every WordPress 7.1 website uses exactly those two numbers. WordPress reads the theme’s viewport settings and generates the corresponding media queries.
What you need to prepare
- A website running WordPress 7.1 or later.
- The active theme is a block theme that supports the Site Editor.
- Your account has permission to edit Styles, templates, or blocks.
- The page being tested contains representative content such as headings, images, buttons, columns, and menus.
- You should test on a backup or staging environment before changing a live site’s design.
If the website still uses a classic theme, you may not see all Responsive styles options. In that case, first confirm that the theme supports the Site Editor instead of looking for a responsive control in the older interface. You can also refer to how to choose a suitable WordPress theme if you are considering switching to a block theme.
How to test a mobile layout in the Site Editor
Review all styles for a block type
- In the admin dashboard, open Appearance > Editor or Appearance > Editor.
- Open the panel Styles, then select Blocks.
- Select the block type you want to check, such as Heading, Button, Group, or Image.
- Open the status list at the top of the panel and find the Viewport group.
- Select Default, Tablet, or Mobile to view the currently applied style values.
- Change a supported property, such as font size, padding, margin, background color, or width.
- Switch between viewports, then use the Preview button to check the differences before saving.
This approach is useful when you want all blocks of the same type to share the same rules. For example, if all second-level headings across the site are too large on phones, go to Styles > Blocks > Heading, select Mobile, and reduce the font size. This change applies site-wide, so check the homepage, posts, archive pages, and templates before clicking Save.
Checking an individual block
- Open the page, post, template, or pattern you want to check.
- In the top toolbar, open the View menu and enable Responsive styles.
- Switch the view to Tablet or Mobile.
- Select the specific block, then open the Settings panel.
- In the Styles section, adjust the property you want to test, such as Typography, Dimensions, Spacing, Color, or Border.
- Switch back to Default to confirm that the base styles have not changed unintentionally.
This is the safer option when the issue appears in only one area. For example, a button in an introductory section may overflow horizontally on phones while the other buttons remain unaffected. You only need to reduce the padding or set an appropriate width for that block, rather than changing every Button block across the site.
WordPress displays a viewport label in the Settings panel when you are editing Tablet or Mobile styles. If you do not see Responsive styles or the Viewport group, an administrator may have disabled responsive-style editing; previously saved settings may still continue to display correctly (see the Responsive styles documentation) (see wordpress.org).
If you frequently need to open multiple pages for testing, combine this workflow with a browser website testing tool to reduce the time spent switching between viewports.
Adjusting breakpoints in theme.json and verifying the result
In WordPress 7.1, theme authors can define Mobile and Tablet breakpoints in theme.json. This is theme configuration, not custom CSS entered in the Additional CSS field. When breakpoints change, responsive styling and some viewport-based block display mechanisms use the new values (see the WordPress 7.1 release page).
Most users do not need to edit this file. If you simply want a better phone layout, prioritize the available Responsive styles controls. Only request changes to theme.json when the current breakpoints do not suit the design—for example, when the layout switches columns too early or too late compared with the theme’s breakpoint.
Post-editing verification workflow
- Choose a representative page with several block types and lengthy content.
- Check Default, Tablet, and Mobile in sequence in the Site Editor.
- Inspect headings, buttons, images, columns, tables, menus, and blocks with colored backgrounds.
- Use Preview to view a representation closer to the user-facing site rather than relying solely on the editor canvas.
- Open the page in a real mobile browser where possible.
- Check landscape orientation, browser zoom, heading length, and content written in languages with longer text.
- Clear the cache if the live site has not updated, then check again in a private window.
Do not test only one of the sizes provided in the editor. A layout may look fine at 390px but overflow around 500–700px, especially when it uses columns, buttons with long labels, or images with fixed widths. Gradually widen and narrow the viewport to find the point at which the layout breaks.
Common issues and solutions
- Changing Tablet does not affect Mobile: set a separate Mobile value because the two states do not inherit directly from each other.
- Responsive options are missing: check that you are running WordPress 7.1 or later, using a block theme, and have the required account permissions and administrator settings.
- The Site Editor change does not match the live page: review the template used by the page, the cache, CSS optimization plugins, and the block’s own styles.
- Want to hide a block on mobile: use the show/hide option in the block’s three-dot menu if the theme or block supports it; changing the font size cannot replace this functionality.
- The toolbar remains shared across all screen sizes: some controls, such as text alignment, apply to every viewport and do not have a separate Mobile value.
If you are preparing to upgrade WordPress or your theme, you should combine responsive testing with the WordPress 7.1 plugin and theme testing checklist. Responsive styles may display correctly in the editor but still be affected by block-creation plugins, caching plugins, or CSS already loaded by the theme.
In summary, WordPress 7.1 responsive breakpoints are most useful when you treat them as part of a testing workflow: identify the affected viewport, adjust the correct scope, recheck Default–Tablet–Mobile, and verify the result in an actual browser. You do not need to write custom CSS for properties already supported by the block and theme. However, custom breakpoints in theme.json, custom block behavior, and issues caused by external CSS may still require action by the theme author or a developer.
Reference source
