chromedp

chromedp brings Chrome DevTools Protocol browser control into Go applications, making it a strong fit for developers building scripted browser workflows. Its range spans page actions, network controls and output capture; concurrent work and remote connections require more care.

Overview

Instead of a standalone automation interface, chromedp is a Go package that drives compatible browsers without an external driver. That makes it useful when browser steps need to live alongside Go application logic, but a poor fit for readers who want to build workflows through a visual, no-code tool.

Chrome runs headlessly by default, and a headless-shell Docker image supports headless environments. The default connection uses remote-debugging pipes, so Chrome opens no debugging port. A separate remote module connects to an already running browser—including one in a container or hosted service—over WebSocket, which uses a debugging port. The choice matters: the pipe route avoids exposing that port, while remote access needs deliberate attention to the debugging endpoint.

Key features

The examples cover the core interactions expected in browser automation: navigation, clicking, reading page text, running JavaScript, filling and submitting forms, and waiting for elements. Network handling adds cookies, HTTP headers, password-protected proxies, request interception, login-session saving and restoration, and HAR recording. This makes chromedp suitable for workflows where page behavior and request handling both need to be controlled from Go.

For output, it can capture screenshots, print pages to PDF, and save browser screencast frames as JPEG files. Those options make it useful for capture and document-generation tasks as well as interaction scripts, without requiring a separate browser driver.

Concurrency calls for discipline. Separate browser contexts can serve as tabs for parallel work, but sharing one context between goroutines can cause races. Teams should keep contexts distinct rather than assume a shared browser session is safe to manipulate concurrently.

There is also a security caveat around site isolation: disabling Chrome site isolation can expose a security feature, and should be limited to pages you trust. Combined with the distinction between pipe and WebSocket connections, this is a tool for developers prepared to make browser and deployment choices explicitly.

Pricing

chromedp is free: its plan costs nothing and provides an MIT-licensed Go package. There is one browser engine, and a self-hosted option is available. The package requires Go 1.27 or newer; there is no paid tier or trial to weigh against the free option. Its zero price makes it accessible for projects that can supply the Go environment and browser setup, but it does not change the engineering work involved in building and maintaining automation in code.

Platforms

chromedp is available for API use and on Linux, macOS and Windows, with a self-hosted option. The headless-shell Docker image is suited to headless environments. Its Go-version requirement is an important compatibility check before adopting it in an existing project.

Who it's for

Choose chromedp when a Go project needs programmatic control of a Chrome DevTools Protocol browser, especially when the workflow includes network handling, session restoration or screenshots and PDFs. It is less suitable for non-developers seeking a graphical automation builder, or for teams that cannot manage context isolation and the security implications of a remote debugging connection.

Questions and feature ideas belong in GitHub Discussions, bugs in the issue tracker, and chat in Discord. The repository uses the MIT license.

Pros and cons

Pros: Browser actions, network controls and capture outputs cover a broad range of Go automation tasks without an external driver.

Pros: The default pipe connection opens no debugging port, and the headless-shell Docker image supports headless deployment.

Pros: Free, MIT-licensed use avoids a software subscription.

Cons: The Go 1.27-or-newer requirement rules it out for projects on older Go versions.

Cons: Sharing a context across goroutines can cause races, so parallel work needs separate contexts.

Cons: Remote WebSocket connections use a debugging port, and disabling site isolation can expose a security feature.

Alternatives

For browser automation choices, see Browser Automation Tools. The other linked options are game memory editors, not direct substitutes for browser automation: Game Memory Editors provides a category view. Pick MemDBG, DOSBox Cheat Engine, ReClass.NET, CoSMOS, ProMod, scanmem, Squalr or Game Cheetah when the task is game memory editing rather than browser control.

Verdict

For Go developers who need browser automation embedded in an application, chromedp is a compelling free option: it combines interaction, network handling and output capture, with a secure-by-default pipe connection. Choose another approach if you need a visual workflow builder, cannot meet the Go requirement, or cannot keep concurrent contexts and remote debugging access carefully managed.