Text Scaling Support in JSON Editor Interfaces

A JSON editor does not have real text scaling support just because the page zooms. It supports text scaling when the editor stays readable and usable after users enlarge text through browser zoom, text-only resize, operating system accessibility settings, or an in-app font control. That matters more in JSON tooling than in many other interfaces because the content is dense, structural, and easy to lose once gutters, highlights, popovers, and validation messages fall out of alignment.

The practical bar is higher than many teams expect. WCAG 2.2 requires text to resize to 200% without loss of content or functionality, and related requirements for reflow and text spacing expose many editor-specific bugs. On mobile, the CSS text-size-adjust property still only affects text inflation on some browsers and is not a universal answer, so durable support still comes from relative sizing, flexible layout, and testing at larger scales.

What Good Support Looks Like

• The code surface stays legible: keys, values, punctuation, indentation, and syntax colors remain readable at larger sizes without characters colliding or lines becoming impossible to follow.
• Supporting UI keeps up: line numbers, fold toggles, error markers, search boxes, replace panels, and formatting buttons remain visible, aligned, and keyboard reachable.
• Layout degrades predictably: side panels wrap or stack, toolbars flow to multiple rows, and popovers stay anchored without covering the only actionable controls.
• User choice wins: if the product offers A+ and A- controls, those settings should be easy to discover, keyboard operable, and preserved instead of resetting on every visit.

Current Standards and Browser Reality

The most useful way to reason about text scaling in 2026 is to separate accessibility requirements from browser-specific behavior:

• WCAG 2.2 Resize Text ( / ): text should resize up to 200% without assistive technology and without losing content or functionality. For editors, that means more than the code area itself. Toolbars, inline errors, dialogs, and settings panels must still work.
• WCAG 2.2 Reflow: content should still work at the equivalent of a 320 CSS pixel viewport width or 400% zoom, except for regions that genuinely require two-dimensional layout. A code viewport may still need horizontal scrolling, but the surrounding UI should not collapse into clipped or unreachable controls.
• WCAG 2.2 Text Spacing: users may increase line height, paragraph spacing, word spacing, and letter spacing. Editor shells often fail here because badges, chips, and side-by-side controls were positioned for one exact line box.
• Mobile text inflation: MDN currently marks text-size-adjust as limited availability and experimental. It is useful for managing text inflation on some phones and tablets, but many browsers ignore it, so it should be treated as a narrow mobile control rather than the core scaling strategy.

Where JSON Editors Usually Break

Most broken editor experiences come from a few repeat mistakes:

• Font size is in pixels, but everything around it is also hard-coded in pixels. The text grows, while the gutter width, row height, icon offsets, and autocomplete panel positions do not.
• Line metrics are duplicated in multiple places. If the editor row is 24px tall, the squiggle overlay is 22px tall, and the hit target is 20px tall, scaling quickly breaks alignment.
• Long JSON values are treated like regular prose. They often need scroll behavior, but the rest of the screen should still reflow. Putting the entire editor shell inside one giant fixed-width pane is where accessibility regressions start.
• Toolbars and side panels refuse to wrap. Search controls, path breadcrumbs, schema hints, and action buttons overlap or disappear long before the code surface becomes the real problem.
• Scaling is tested only with browser zoom. Text-only resize, mobile text inflation, and operating-system large-text settings often reveal different failures than full-page zoom.

Implementation Pattern That Holds Up

The safest pattern is to define the editor's font size once, let the code surface inherit from it, and size editor-adjacent UI relative to that value. Use a monospace stack for the content area, keep line height unitless, and size gutters and indentation with character-based units instead of fixed pixels.

.json-editor {
  --editor-font-size: 1rem;
  --editor-line-height: 1.5;
  display: grid;
  grid-template-columns: max-content minmax(0, 1fr);
  min-height: 0;
}

.json-editor-toolbar {
  grid-column: 1 / -1;
  display: flex;
  flex-wrap: wrap;
  gap: 0.5rem;
  margin-bottom: 0.75rem;
}

.json-editor-gutter,
.json-editor-surface {
  font:
    400 var(--editor-font-size) / var(--editor-line-height)
    ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
}

.json-editor-gutter {
  min-width: 4ch;
  padding-inline: 1ch;
}

.json-editor-surface {
  min-width: 0;
  overflow: auto;
  white-space: pre;
  tab-size: 2;
}

.json-editor-popover {
  max-width: min(32rem, 100%);
  font-size: 0.9375rem;
}

.json-editor-button {
  min-height: 2.75rem;
  padding-inline: 0.875rem;
  font-size: 0.9375rem;
}
          

• Use rem for general UI and ch where character width matters. Gutters, indentation, and line-number columns scale more predictably that way.
• Keep line height unitless. It scales with the font, and overlays can derive from the same value instead of repeating pixel math in several components.
• Wrap controls outside the scrollable code surface. Long JSON lines can scroll; the search bar and action buttons should not need the same horizontal scroll to remain reachable.
• Anchor overlays to text metrics, not screenshots of the default state. Suggestions, lint popovers, error underlines, and selection rectangles should all derive from the active line box.
• Treat text-size-adjust as optional mobile tuning. It can help with text inflation on some devices, but the editor still needs to work when that property is ignored.

Testing Checklist for a JSON Editor

Testing should cover more than a single browser zoom shortcut:

• Browser zoom: check at 200% for WCAG Resize Text and at 400% to catch reflow issues in surrounding controls.
• Narrow viewports: simulate roughly 320 CSS pixels of available width and verify that the page chrome, toolbar, and settings panels still work even if the code pane itself needs horizontal scroll.
• Text-only growth: test browser text resizing where available, user stylesheet overrides, and operating-system large-text settings.
• Mobile behavior: verify real phones or emulation with large text enabled so you can spot text inflation issues, clipped dialogs, and tap targets that are now too close together.
• Editor-specific cases: use long keys, very long string values, deep nesting, schema errors, autocomplete menus, search and replace panels, and diff or split-view layouts if the product has them.
• Text spacing overrides: confirm there is no loss of content or functionality when line height, paragraph spacing, letter spacing, and word spacing are increased to WCAG 2.2 test values.

Decision Rule

If a larger font forces the JSON text itself to use more scrolling, that can be acceptable for a code-like interface. If larger text makes controls disappear, overlap, stop lining up with the code, or become unreachable by keyboard, the editor does not have good text scaling support yet. The goal is not a perfectly identical layout at every size. The goal is a JSON editor that remains understandable, operable, and trustworthy when the user needs bigger text.