WordPress 7.1's beta cycle got real in July, with Beta 1 landing on July 15 and weekly betas scheduled through the rest of the month ahead of a final release targeted for August 19, 2026. The headline feature isn't flashy, but it fixes a genuinely old annoyance: Gutenberg 23.5 replaces the fixed desktop/tablet/mobile preview toggle with a unified, freely resizable device preview, and pairs it with Responsive Styling — the ability to style individual blocks per viewport directly inside the block editor, without leaving it for custom CSS or a theme-level media query.
What actually shipped
The July 3 Call for Testing formally opened Responsive Styling to broader feedback, letting developers and site builders style blocks per viewport width directly in the editor interface. That's paired with Gutenberg 23.5's replacement of the old three-button device toggle (desktop, tablet, mobile) with a single, freely draggable preview pane that can be resized to any width — not just the three preset breakpoints WordPress has shipped with for years. Alongside that, WordPress 7.0.1 landed on July 9 as a pure bug-fix release, bundling 13 Core tickets and 13 Gutenberg fixes with no new features, which is itself a signal of how the project is managing the 7.x line: stabilize the point releases, ship the bigger structural changes in the numbered minor releases like 7.1.
Why the fixed device toggle was a real limitation
The old desktop/tablet/mobile toggle assumed three fixed breakpoints represented the meaningful range of devices your site needed to look good on. That assumption has been increasingly wrong for years. Foldable phones, ultra-wide monitors, split-screen tablet multitasking, and browser windows resized to arbitrary widths on desktop all produce layouts that don't cleanly match "mobile," "tablet," or "desktop" as WordPress previously defined them. A site that looked correct at the three preset widths could still break at 480px, or 900px, or any of the countless in-between widths real visitors actually use — and there was no way to preview or fix that inside the editor without exporting to a browser dev tools panel or shipping custom CSS blind.
A freely resizable preview closes that gap directly. Site builders can now drag the preview pane to any width and immediately see how a block responds, rather than guessing at in-between breakpoints or relying on the three fixed presets as a proxy for "it'll probably be fine in between." Combined with Responsive Styling — actual per-viewport block style overrides configurable in the editor UI — this moves a meaningful chunk of what used to require custom CSS or a page-builder plugin into WordPress's native block editing experience.
What this means if you build or maintain WordPress sites
For agencies and freelance developers building client sites, this closes a persistent gap between what WordPress's native editor could do and what clients actually needed, which has historically pushed a lot of responsive-design work into either custom theme CSS or third-party page builder plugins (Elementor, Divi, and similar tools built entire business models partly around WordPress's weaker native responsive controls). Native, per-viewport block styling reduces the case for reaching for a heavyweight builder plugin just to get responsive behavior right — though it doesn't eliminate it, since those tools still offer broader layout and design system capabilities beyond responsive breakpoints alone.
For teams maintaining existing WordPress sites with custom CSS handling responsive behavior, this is worth an audit rather than an immediate migration. Native Responsive Styling and custom media-query CSS can coexist, but running both approaches for the same elements is a recipe for specificity conflicts and inconsistent behavior across breakpoints. As 7.1 stabilizes, it's worth identifying which of your custom responsive CSS rules could move into native block settings — starting with new components rather than attempting a wholesale retrofit of an existing site.
SEO and accessibility implications worth tracking
Responsive design quality has direct SEO consequences that are easy to overlook when a feature like this gets filed purely under "developer experience." Search engines have used mobile-friendliness and layout stability as ranking signals for years, and a site that renders correctly at exactly three preset widths but breaks at in-between viewport sizes real visitors actually use can quietly accumulate poor Core Web Vitals scores — particularly cumulative layout shift — without the site owner ever seeing the problem in their own testing, precisely because their own testing tools defaulted to the same three legacy breakpoints WordPress just moved away from. Site owners and agencies should treat the new resizable preview as a testing tool worth using deliberately across a wider range of widths, not just as an editing convenience, specifically to catch these previously invisible layout regressions before they affect search ranking or user experience metrics.
Accessibility carries a similar dynamic. Users with low vision frequently browse at non-standard zoom levels or with browser windows resized in ways that don't match any of the three legacy breakpoints, and layout breakage at those in-between widths is functionally an accessibility barrier, even though it's rarely audited as one. Native Responsive Styling gives site builders a more direct tool to close that gap without waiting for a dedicated accessibility remediation pass.
The bigger pattern: block editor closing gaps with page builders
This release continues a multi-year trend where the core WordPress block editor has steadily absorbed capabilities that used to require a dedicated page-builder plugin — first with basic layout blocks, then with more sophisticated pattern and template systems, and now with native responsive controls. That doesn't make third-party builders obsolete; many offer visual design capabilities, template marketplaces, and workflow tooling that core WordPress still doesn't match. But it does shift the calculus for teams evaluating whether a new project needs a page builder at all, especially for simpler sites where the primary gap used to be exactly this kind of responsive control.
It's also a reminder that "boring" incremental improvements to a mature CMS are often more consequential for day-to-day site-building work than splashier feature announcements. Responsive Styling won't make a keynote highlight reel, but it addresses a specific, recurring pain point that anyone who's built a WordPress site professionally has hit repeatedly: the gap between "looks right at the three preset widths" and "looks right at the actual width a real visitor's device or window happens to be."
How the page-builder ecosystem is likely to respond
Third-party page builder plugins aren't standing still while core WordPress absorbs more of their differentiating functionality, and it's worth anticipating how that competitive dynamic plays out rather than assuming it's a one-directional squeeze. Historically, when core WordPress has absorbed a capability that used to differentiate premium plugins — reusable blocks, full-site editing, pattern libraries — established builder plugins have responded by pushing further up the value chain: deeper e-commerce integration, more sophisticated dynamic content and conditional logic, tighter design-system tooling, and template marketplaces that core WordPress has no equivalent for. Expect the same pattern here. Responsive Styling closes a specific, well-defined gap, but it's unlikely to be the last word on visual design flexibility, and builder plugins will likely continue to justify their premium pricing on capabilities well beyond basic per-viewport styling.
For teams currently paying for a page builder license primarily to get decent responsive control, this release is a legitimate prompt to re-evaluate that specific line item — but not necessarily to abandon the plugin entirely if it's also providing template libraries, e-commerce features, or team collaboration tooling core WordPress still lacks.
A note on release stability during beta
Weekly betas through an entire release month, as 7.1 is running, is WordPress's standard approach for a minor version carrying structural editor changes, but it's worth being deliberate about when in that cycle you actually start relying on new behavior in a client-facing project. Early betas frequently carry rough edges in exactly the kind of UI-heavy feature Responsive Styling represents — inconsistent preview rendering, edge cases in how existing blocks interact with new per-viewport controls, or interaction bugs that get ironed out over successive weekly builds before the August 19 general release. Treating Beta 1 as production-ready is a different risk profile than treating Beta 4 or 5, closer to release, the same way — and agencies managing client timelines should communicate that distinction rather than presenting all pre-release builds as equally stable.
Practical takeaways
Start testing your active projects against WordPress 7.1's weekly betas now rather than waiting for the August 19 release, particularly if your site relies on custom responsive CSS that might interact with the new native controls. Audit existing custom media-query CSS for cases that could move to native Responsive Styling as you touch those components anyway, rather than treating it as a standalone migration project. Re-evaluate whether new, simpler projects genuinely need a heavyweight page-builder plugin now that native block editing covers more responsive-design ground, weighing that against the design flexibility and workflow features those plugins still offer beyond responsiveness. Use the new freely resizable preview to actually check in-between breakpoints during development, rather than relying on the three legacy presets as a proxy for "good enough." And keep an eye on the 7.1 changelog through its beta cycle, since a release this close to shipping structural editor changes tends to surface edge cases in weekly betas that are worth catching before the general release lands on client sites.
WordPress's responsive-design story has lagged behind dedicated builder tools for years. Native Responsive Styling and the resizable preview in 7.1 don't fully close that gap, but they meaningfully narrow it — and for a huge number of WordPress sites that never needed a full page-builder plugin's feature set in the first place, that narrowing is the more relevant story than any single headline feature.