go doc - Terminal Documentation Viewer

Learn how to use go doc to read package and symbol documentation directly from the terminal, including flags, common patterns, and how it differs from godoc.

go doc prints documentation for Go packages, functions, types, and methods directly in your terminal. It reads the same doc comments you write in your source code, so you don't need a web browser, a separate server, or an internet connection to look up how a standard‑library function works.

What go doc Does

When you run go doc with a package name or symbol, it searches your local Go installation and module cache for that package’s source code. It extracts the package‑level comment and the documentation comment attached to the requested symbol, formats them, and prints them to standard output.

If you run go doc with no arguments inside a package directory, it shows the documentation for that package.

Runs Entirely Offline:

go doc never fetches documentation from the internet. It uses only the source code already on your machine — the standard library, modules downloaded into the module cache, and packages in your GOPATH. If a package’s source is not present locally, go doc cannot show its documentation.

Why a Terminal‑First Documentation Tool Matters

Before go doc, reading Go documentation often meant opening a browser and visiting pkg.go.dev or running the godoc server. Both work, but they break your flow when you’re deep inside a terminal session. With go doc, you can check a function signature, read a package’s overview, or verify what a method does in a couple of keystrokes — without ever leaving your editor or command line.

This is especially useful when you’re working in an environment with limited or no internet access, such as a build container, an air‑gapped machine, or a slow connection.

Viewing Documentation for the Current Package

If you’re inside a directory that contains Go source files and you just want to see the package’s overview, run go doc with no arguments:

cd myproject
go doc

This prints the package comment (the block of text immediately before the package declaration) and lists all exported symbols — functions, types, variables, and constants — with their one‑line summaries. The output mirrors the top‑level documentation you’d see on pkg.go.dev, but it’s generated locally.

Quick Sanity Check:

If go doc shows a clean package comment and a list of exported identifiers, your package is properly documented and its public API is discoverable.

Looking Up a Specific Package

To view documentation for a package in the standard library, pass its import path:

go doc fmt

The output begins with the package declaration and import path, followed by the full package comment, then a list of all exported symbols with their signatures. Here’s a trimmed example:

package fmt // import "fmt"
Package fmt implements formatted I/O with functions analogous
to C's printf and scanf. The format 'verbs' are derived from C's
but are simpler.
func Errorf(format string, a ...any) error
func Fprint(w io.Writer, a ...any) (n int, err error)
func Fprintf(w io.Writer, format string, a ...any) (n int, err error)
func Fprintln(w io.Writer, a ...any) (n int, err error)
...

This single command replaces a web search when you need a quick reminder of what fmt offers. You can also pass a full module path for a dependency that’s already in your module cache:

go doc github.com/gorilla/mux

If the package isn’t in the cache, go doc will return an error. You’d need to add it to your module with go get first.

Looking Up a Specific Symbol

To see the full documentation for a function, type, or method, append a dot and the symbol name:

go doc fmt.Println

The output focuses on just that symbol:

package fmt // import "fmt"
func Println(a ...any) (n int, err error)
    Println formats using the default formats for its operands and writes to
    standard output. Spaces are always added between operands and a newline
    is appended. It returns the number of bytes written and any write error
    encountered.

This is the fastest way to check a function signature and read its documented behavior while you’re writing code.

Types and Their Methods

For a type, go doc prints the type’s definition and its doc comment, along with a list of its exported methods. To zoom into a specific method, use Type.Method:

go doc net/http.Client
go doc net/http.Client.Do

The first command shows the Client struct and all its methods; the second shows only the Do method’s documentation.

If a type embeds another type, you can access the embedded type’s methods through the outer type as long as the method is promoted. go doc follows the same promotion rules the compiler does.

Flags That Change Output

Four flags control how go doc searches and what it displays. They’re especially useful when you’re debugging a package or exploring its internals.

Showing Unexported Symbols: -u

By default, go doc shows only exported identifiers — those starting with an uppercase letter. The -u flag includes unexported functions, types, methods, and fields.

go doc -u mypackage

Unexported Symbols Have No Guarantee of Stability:

Documentation for unexported symbols exists primarily for maintainers of the package itself. Relying on an unexported API from outside the package will break if the implementation changes, because unexported identifiers are not part of the public compatibility promise.

Viewing Source Code: -src

The -src flag prints the full source code of the requested symbol — doc comment, declaration, and body — rather than the formatted documentation.

go doc -src fmt.Println

This is useful when the doc comment doesn’t answer your question and you need to see the implementation, or when you want to verify how a standard‑library function handles edge cases.

Case‑Sensitive Matching: -c

Go allows exported identifiers that differ only in case (e.g., New and new). The -c flag tells go doc to respect the exact case you typed instead of performing a case‑insensitive match.

go doc -c unicode/utf8.DecodeRune

Without -c, the command might match a different symbol if one exists. With -c, you get an error if the precise case doesn’t exist.

Treating main Packages as Regular Packages: -cmd

Packages declared package main are normally treated as commands. Their exported symbols are hidden from the top‑level package documentation because end users rarely interact with them directly. When you’re developing a command, you may want to see those symbols. The -cmd flag exposes them:

go doc -cmd mycmd

This is useful inside a project that defines multiple commands in a single module and you need to cross‑reference shared utilities.

How Beginners Should Think About go doc

Think of go doc as a local, text‑only version of pkg.go.dev. It’s not a learning tool that explains concepts from scratch — it displays the same doc comments that the package author wrote. If those comments are well‑written, go doc becomes a quick, reliable reference. If they’re sparse, go doc still gives you the exact function signatures, which is often enough to understand what arguments a function expects.

You don’t need to memorize every flag. Start with go doc <package>.<symbol> and the output will immediately show you the signature and the author’s explanation. That single pattern covers most day‑to‑day usage.

Common Mistakes When Using go doc

Requesting Documentation for an Unexported Symbol:

go doc mypkg.myFunc will fail with an error like doc: no symbol myFunc in package mypkg if myFunc starts with a lowercase letter. The tool only exposes exported symbols by default. If you need to see unexported documentation, add the -u flag, but remember that those symbols are not part of the package’s public contract.

A second common mistake is assuming go doc can look up any package on the internet. It cannot. The package’s source must already exist on your machine — either in the standard library, in the module cache, or in a directory inside your GOPATH. If you get an error that the package cannot be found, you likely need to add it as a dependency or download it with go get.

Another pitfall: running go doc from outside a module and expecting it to resolve a package from a remote repository. Without a go.mod file to guide dependency resolution, go doc can only search the standard library and your local workspace. Set up a module first if you need to document third‑party code.

go doc and godoc Are Different Tools

Older Go documentation often references godoc. That tool generates HTML documentation and can run a local web server. The godoc binary is not installed by default in recent Go releases; go doc has replaced it for terminal‑based documentation lookups.

go doc is simpler, faster for quick lookups, and integrated directly into the go command. Use godoc if you need to generate static HTML files or run a documentation server for an internal package repository, but reach for go doc when you just need to read a comment in your terminal.

Integrating go doc Into Your Workflow

Beyond one‑off lookups, go doc fits into a few productive patterns:

  • During code review: When you encounter an unfamiliar function, go doc <pkg>.<Func> lets you verify its contract without context‑switching.
  • In shell scripts and CI: You can parse the output of go doc to check whether a certain symbol exists or to extract its signature, though the output format is meant for humans and may change between Go versions. For programmatic needs, use go doc -src or the go/build package.
  • With editor integration: Many editors can run go doc and display the result in a pop‑up. Check whether your editor’s Go plugin supports a “Show Documentation” command.

The key benefit is speed: you stay in the same terminal, your fingers stay on the keyboard, and you get the answer in seconds.

Summary

go doc solves a specific, common problem — “What does this function do, and what arguments does it take?” — without pulling you out of the terminal. It works entirely offline, respects the same doc comments that drive pkg.go.dev, and requires no setup beyond having Go installed.

The habit worth building: whenever you type a function name you don’t fully remember, run go doc on it. You’ll reinforce your mental model of the standard library and third‑party packages, and you’ll catch subtle details (like which errors a function can return) that are easy to miss when skimming code alone.