How to Stop chromium/html2image from Sending Error Messages

Short answer: start with html2image’s quiet mode. In Python, create Html2Image(disable_logging=True); in the CLI, use -q or --quiet. Chromium runs as a separate process, so html2image quiet mode will not silence every browser line. Pass Chromium flags through custom_flags or browser.flags, use --v=-1 for Chromium logging, and redirect the browser process’s stderr when you only need a clean terminal. Use --noerrdialogs for graphical error dialogs. Diagnose the source before hiding output, because a warning can indicate a real failed capture.

1. Apply the smallest fix first

Run one capture with all output visible.
If the line is emitted by html2image, enable disable_logging=True or the CLI’s --quiet/-q.
If it is emitted by Chromium, add a Chromium logging flag or redirect stderr at the process boundary.
If a graphical dialog appears, add --noerrdialogs.
Keep the original stderr and exit status in CI until you know the message is harmless.

These controls affect different channels. A quiet html2image logger cannot control a child Chromium process, and --noerrdialogs suppresses dialogs rather than terminal stderr.

2. Python: quiet html2image and Chromium together

Install html2image in the environment that runs the capture, then use this complete example:

from html2image import Html2Image

hti = Html2Image(
    disable_logging=True,
    custom_flags=["--v=-1", "--noerrdialogs"],
)

hti.screenshot(
    html_str="<h1>Hello</h1>",
    save_as="out.png",
)
print("saved out.png")

disable_logging=True handles informational messages produced by html2image. The entries in custom_flags are passed to Chromium: --v=-1 reduces Chromium logging and --noerrdialogs prevents browser error dialogs.

Keep diagnostics while debugging

Do not begin with every suppression flag. Remove disable_logging and --v=-1, run one capture, and save the complete stderr. Confirm that the image exists, has a non-zero size, and represents the expected page. Re-enable quiet mode only after the capture is reliable.

Use the browser object when your version exposes it

Some html2image versions configure flags through a browser object instead of the constructor. The equivalent pattern is:

from html2image import Html2Image

hti = Html2Image()
hti.browser.flags = ["--v=-1", "--noerrdialogs"]
hti.screenshot(html_str="<h1>Hello</h1>", save_as="out.png")

Use the API shape provided by the html2image version installed in your environment. If assigning browser.flags raises an attribute error, use the documented custom_flags constructor argument instead.

3. Command line: use quiet mode and preserve your own output

For the html2image command-line interface, add -q or --quiet:

html2image --quiet ...

The exact input and output options depend on the html2image CLI version. Keep your program’s result on stdout and route browser diagnostics separately. At the shell boundary, this pattern leaves stdout available for your wrapper while writing stderr to a file:

html2image --quiet ... 1>result.txt 2>chromium.stderr

Inspect chromium.stderr whenever the command exits non-zero or the image is missing. Redirecting output is a presentation change; it does not repair a failed browser launch.

4. Chromium flags and what each one changes

Control	Controls	Use it when	Limit
`disable_logging=True`	html2image informational output	You want html2image’s own messages hidden	Does not silence Chromium
`-q`/`--quiet`	html2image CLI output	You run the CLI	Does not silence every child-process line
`--v=-1`	Chromium logging verbosity	Chromium stderr is noisy after the capture is known to work	Can hide useful diagnostics
`--noerrdialogs`	Chromium graphical error dialogs	A desktop or virtual display shows dialogs	Does not remove all stderr

Pass Chromium switches through html2image’s custom_flags or browser.flags. Do not add unrelated flags blindly. In particular, --no-sandbox is an environment-dependent workaround, commonly relevant to some containerized root setups; it changes the browser’s security posture and should only be used when the execution environment requires it.

5. Redirect Chromium stderr without changing the capture

If the screenshot is correct and you only need a clean terminal, redirect stderr where you launch the browser process. A Python wrapper can keep its own status message on stdout while capturing child-process diagnostics:

import subprocess

completed = subprocess.run(
    ["your-wrapper-command", "--quiet"],
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE,
    text=True,
    check=False,
)

print(completed.stdout)
if completed.returncode != 0:
    print(completed.stderr, flush=True)
    raise SystemExit(completed.returncode)

During development, write stderr to a durable CI artifact instead of discarding it. That preserves the evidence needed to distinguish a harmless warning from a browser crash, missing executable, navigation timeout, or permission problem.

6. Diagnose the message before suppressing it

Identify the emitter. html2image messages usually appear with the library’s formatting; Chromium messages come from the child browser process. A graphical dialog is a separate case.
Check the exit status. A zero exit status does not prove the page was captured correctly, but a non-zero status requires investigation.
Validate the artifact. Check that the file exists, is not empty, opens as the expected format, and contains the intended page.
Repeat with visible stderr. Compare a successful and failed run, including the executable path and browser version.
Only then reduce logging. Keep a debug mode that restores full stderr for future incidents.

Some Chromium warnings are harmless and can be difficult or impossible to remove completely when the screenshot is generated correctly. Treat the image and process status as part of the diagnosis, not the presence of a scary-looking line alone.

7. Browser versions, executable paths, and CI

Record the Chromium executable path and browser version in CI logs. Headless packaging changed across Chromium milestones: downloadable chrome-headless-shell binaries began with M118, and from M132 the old headless implementation was removed from the regular Chrome binary. A flag or executable path that works on one machine may therefore behave differently after an image or browser upgrade.

When a warning appears after an upgrade, compare:

the resolved Chromium or Chrome executable path;
the exact browser version;
the html2image version;
container user and sandbox permissions;
the complete command-line flags;
exit status and output-file validation.

8. Reliability and performance checklist

Launch one known-good URL before testing complex pages.
Reuse a stable browser setup where your html2image version supports it; repeated process startup adds latency.
Keep stderr available in debug and CI failure artifacts.
Use a bounded timeout in the wrapper so a stuck browser cannot block a job forever.
Capture the browser version with every build that produces screenshots.
Do not treat log suppression as a performance optimization; it mainly changes output volume.
In containers, test as the same user and with the same sandbox permissions used in production.

9. Troubleshooting common errors

Symptom	Likely cause	Fix
html2image lines remain after `disable_logging=True`	The lines come from Chromium	Use `--v=-1`, or redirect Chromium stderr
A dialog still appears	Dialog suppression was not enabled	Add `--noerrdialogs` through `custom_flags` or `browser.flags`
The command is quiet but no image is created	A real launch, navigation, permission, or timeout failure was hidden	Restore full stderr, inspect the exit status, and validate the executable path
`--v=-1` has no visible effect	The line is not Chromium verbosity output, or another process emits it	Identify the emitting process and redirect that process’s stderr
`custom_flags` is rejected	Your installed html2image version uses a different configuration path	Use the version’s documented `browser.flags` interface or upgrade consistently
Works locally, fails in a container	Executable path, sandbox, user, or headless packaging differs	Log the path and version; only consider environment-specific flags such as `--no-sandbox` when required
Warnings appear only after a browser update	Chromium milestone or packaging behavior changed	Compare versions and headless executable packaging, then retest flags

10. Or skip the browser setup

ScreenshotNeo provides a website screenshot API and MCP server. One request returns a PNG, JPEG, WebP, or PDF, so your code does not need to install or tune Chromium:

See the ScreenshotNeo API docs for the available options.

cURL

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

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and each response reports its result through X-Page-Verdict and X-Billed headers. Its MCP server includes take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

11. FAQ

Are Chromium warnings always real errors?

No. Some warnings are harmless when the screenshot is correct, but verify the artifact and exit status before hiding them.

Does `--noerrdialogs` silence terminal output?

No. It targets graphical error dialogs. Use Chromium logging controls or stderr redirection for terminal output.

Should I use `--no-sandbox` to remove warnings?

Only when the execution environment requires it, such as some containerized root setups. It changes the browser’s security posture and is not a general logging switch.

Why does quiet mode work for html2image but not Chromium?

They are separate processes with separate output channels. html2image controls its own logger; Chromium controls its own stderr.

What should a CI failure retain?

Keep the full stderr, exit status, executable path, browser version, html2image version, command flags, and the generated artifact or its validation result.