People comparing gopath vs goroot, goroot vs gopath, or searching goroot, golang goroot, go root, go goroot, and gopath goroot want a clean mental model: one variable names the Go installation, the other names your workspace conventions. The query both gopath and goroot are the same directory usually appears after a misconfiguration; the two should stay on different paths in normal setups. This article matches that intent and points to Go environment variables for the wider list.
Tested with Go 1.24 on Linux.
What is GOROOT?
GOROOT is the root of the Go distribution: the src, bin, and pkg trees that ship with Go (including the standard library under GOROOT/src). The go tool finds its own standard library and tools relative to this directory.
Check the effective value:
go env GOROOTOn a typical Linux install from the official tarball, go env GOROOT prints the directory where you unpacked Go (often /usr/local/go). Your path will differ if you use a version manager or a distro package.
You should not point GOROOT at a random project folder or at your default module workspace. An older mistake is setting GOROOT to $HOME/go; that directory is the default GOPATH workspace, not the toolchain—doing both roles in one tree is exactly what confuses gopath vs goroot.
What is GOPATH?
GOPATH is a workspace root. Each entry (there is usually one) is expected to contain src, pkg, and bin subdirectories: source lived under GOPATH/src in pre-module workflows, compiled archives under GOPATH/pkg, and installed commands under GOPATH/bin. If GOPATH is unset, Go uses a default such as $HOME/go on Unix.
go env GOPATHWith modules (default for development outside GOPATH/src mode), your project can live anywhere if it has a go.mod; downloads are tracked separately:
go env GOMODCACHEGOMODCACHE is often $GOPATH/pkg/mod, which reuses the pkg subtree but is not the same as “all code lives in GOPATH/src” anymore.
Gopath vs goroot in practice
| Idea | GOROOT | GOPATH |
|---|---|---|
| Role | Toolchain + standard library | Your workspace roots (src / pkg / bin layout) |
| Typical path | /usr/local/go (example) |
$HOME/go (default) |
| Set manually? | Rare (non-standard install only) | Optional; default exists |
For day-to-day work you mostly run go env GOROOT and go env GOPATH to verify assumptions instead of exporting both everywhere.
Same directory for GOPATH and GOROOT?
Avoid making both gopath and goroot the same directory. The toolchain expects to own everything under GOROOT; GOPATH is for your code and build outputs. Collapsing them:
- mixes standard library sources with your repositories,
- makes upgrades risky (overwriting your tree),
- breaks the mental model readers use when they search goroot gopath together.
Use separate directories: install Go into something like /usr/local/go (GOROOT implied) and keep $HOME/go or another path as GOPATH.
Changing GOPATH (optional)
You can set GOPATH to another directory if you need a different workspace root. On Unix you can persist:
export GOPATH=$HOME/work-go
export PATH=$PATH:$GOPATH/binOr use:
go env -w GOPATH=/path/to/workspaceOn Windows, use System Properties → Environment Variables or go env -w GOPATH=c:\go-work. Do not point GOPATH at the directory that contains only the Go toolchain; that directory is GOROOT’s job. For a longer walkthrough, see set GOPATH variable.
When to set GOROOT explicitly
Official installs record the layout the go binary expects. Set GOROOT only when documentation for your install method says so—for example, unpacking the tarball to a custom prefix and wiring PATH and GOROOT per Install Go from a non-standard location. If go env GOROOT already prints a sensible path, do not override it “just in case.”
Summary
Gopath vs goroot comes down to roles: golang goroot and go root mean the Go installation tree; GOPATH is your conventional workspace (default under $HOME/go) and still matters for GOPATH/bin, default cache locations, and legacy GOPATH-mode projects. Goroot vs gopath is not a competition—both names appear in go env, but they must not label the same directory in healthy setups. Modules shifted most source out of GOPATH/src, yet go env GOPATH and go env GOMODCACHE remain useful when debugging paths. For the full variable list, keep Go environment variables open beside this page.
References
- Command documentation — GOPATH environment variable
- Installing Go — official guide
- How to Write Go Code (modules)
Frequently Asked Questions
1. What is GOROOT (go goroot / go root)?
go command live under that tree. You normally do not set it; the go command infers it from its own install location.2. What is gopath vs goroot or goroot vs gopath?
go install binaries and the default module cache parent unless overridden). They answer different questions: toolchain location vs where user code and build artifacts are organized.3. Can both GOPATH and GOROOT be the same directory?
src, pkg, and bin for your projects and installed commands. Pointing both at one folder mixes standard library trees with your code and breaks the intended layout.4. When must I set GOROOT?
go binary cannot infer its root, or for unusual distro layouts. Prefer fixing PATH to $GOROOT/bin after a proper install per the official install guide.5. Where do modules download if not under GOPATH/src?
GOMODCACHE (see go env GOMODCACHE), often inside your GOPATH as …/pkg/mod, which is separate from GOPATH/src legacy layout.