Skip to content
Sizzy home
The Sizzy developer workspace

One workspace for building, debugging, and testing the web

Explore Sizzy's developer browser: project workspaces, synchronized devices, isolated sessions, debugging tools, screenshots, terminals, and coding agents.

A typical fix crosses several tools: start the app, reproduce a bug, inspect the response, change the code, and check the result. Sizzy brings those steps into one desktop browser. Here is a concrete workflow for a web app with an admin, a customer, and a guest experience.

1. Open the project with its working context

Save the repository path, development command, preferred editor, and local URL in a Sizzy project. Its device presets, workspace tabs, and sessions return with it, so you can switch between a storefront and its admin app without rebuilding the setup.

Keep notes, todos, bookmarks, and code snippets beside the page.

Use the project switcher to open the repository in your editor or file manager.

Start the development command in the Processes tab and read its output below the browser.

Use Butler, Sizzy's command palette, to find commands without hunting through menus.

2. Compare layouts and user roles side by side

Open the app on phone, tablet, and desktop viewports. Synchronized navigation, scrolling, clicking, and typing let you repeat a flow across widths. When checking different roles, assign separate browser sessions to the devices: each has its own cookies, cache, and local storage.

Use one session across widths when checking the same user's responsive layout.

Use separate admin, customer, and guest sessions when checking permissions and account-specific UI.

Keep sessions scoped to a project or reuse a global session across projects.

Clear one session's cache when you need to reproduce a first visit.

3. Follow the bug from the page to the data

When a customer sees the wrong cart total, compare console output across devices, inspect the page with docked Chromium DevTools, and check the request in the API client. The debugging panel also includes cookie and local-storage editors and CSS overrides for investigating layout changes.

Use the unified console to compare errors from several devices.

Inspect an element and its computed styles in DevTools.

Send REST or GraphQL requests in the API client while working on the UI.

Inspect session data before assuming a visual mismatch is a CSS bug.

4. Run the fix and its checks beside the browser

Docked terminals open in the project folder. Run a command there, or use the Processes tab for the project's development server, build, and tests. Coding-agent sessions use your installed, signed-in Claude Code or Codex CLI, with project context and screenshots attached from a device.

Keep terminal output visible while watching the page update.

Include the affected route, session, viewport, and expected result in a fix request.

Attach a screenshot and mention relevant project files when asking an agent to investigate.

Review the code and rerun the failing flow after an agent finishes; an agent response is not a test result.

5. Capture the result and finish browser coverage

Capture a viewport or full-page screenshot to document the fix, use Photo Studio for composed product images, or record an interaction. Save the device size and user state with your bug report so someone else can reproduce the same check.

Capture both the failing state and the verified result at the same width.

Check intermediate widths as well as named device presets.

Sizzy uses Chromium: device presets do not turn it into Safari, Firefox, or a physical phone.

Finish with the real browsers and hardware your product supports, especially for mobile keyboard, browser-toolbar, and touch behavior.

Try it with your next bug

Save a real project, its repository path, and its local URL.

Choose the widths and account states involved in the bug.

Reproduce, inspect, change, and rerun the same interaction.

Capture the result and verify any browser-specific behavior on the target browser.

Frequently asked questions

Is Sizzy only a responsive testing tool?

Responsive testing is one part of Sizzy. The desktop browser also organizes projects, isolates browser sessions, brings debugging and API tools into one panel, captures screenshots and video, and runs terminals and coding agents beside the page.

Does Sizzy replace my editor or a real-device test service?

You can keep your preferred editor and use Sizzy for the browser side of development. Its Chromium viewports help with layout and interaction checks, but Safari, Firefox, and hardware-specific behavior still need verification in those environments.

What do I need to use coding agents in Sizzy?

Install and sign in to the Claude Code or Codex CLI you want to use. Sizzy runs sessions through that CLI and adds project context, file mentions, and device screenshots. Access to the underlying agent comes from your existing account.

Related guides