A tag is a human-readable name for an image. You have used tags to pull images; now you set them on your own. Good tagging is what makes images shareable and deployable.
An image reference can carry more than a name and version. The full shape is:
registry/namespace/name:tag
For docker.io/library/nginx:1.27, the registry is docker.io, the
namespace is library, the name is nginx, and the tag is 1.27.
Pulling official images you skip most of it and write nginx:1.27,
because Docker fills in the defaults. When you publish your own images,
you spell out the parts that matter - especially the namespace, which
is usually your Docker Hub username or organisation.
You have already tagged during a build:
docker build -t myapp:1.0 .
docker tag gives an existing image another name. It does not copy the
image - both tags point at the same underlying image:
docker tag myapp:1.0 myapp:latest
docker tag myapp:1.0 registry.example.com/team/myapp:1.0
The first adds a latest alias. The second gives the image a name that
includes a registry and namespace, which is the form you need before
pushing it somewhere. Tagging is how you take a locally built
myapp:1.0 and label it with its destination.
Prefer meaningful, immutable tags - a version number, a release name,
or a Git commit hash - over relying on latest. A tag like
myapp:1.4.2 or myapp:2026-07-25 tells you exactly what is deployed.
It is common to push both a specific tag and latest for the same
image, so users have a stable pointer and a precise one.
docker tag SOURCE TARGET - add another name to an existing image