What characters are allowed in a Docker tag?

A tag may contain lowercase and uppercase letters, digits, underscores, periods and hyphens, up to 128 characters, and may not start with a period or hyphen. This tool only emits characters from that set so every generated tag is valid for docker push.

Why combine a version with a git hash?

A tag like 1.4.0-a1b2c3d ties a human-readable release to the exact commit it was built from. It stays readable for humans while remaining traceable, which is a common immutable-tag convention in CI pipelines.

Should I rely on the latest tag?

Generally no. The latest tag is mutable and points at whatever was pushed most recently, which makes deployments non-reproducible. Prefer an immutable tag such as a version or a git sha, which is why this tool favours those styles.

What does the timestamp style produce?

It emits a sortable UTC stamp such as 20260606-1430, optionally combined with a short hash. Timestamp tags are useful for nightly or continuous builds where there is no formal version bump.

Is anything sent to a server?

No. All tags are produced locally in your browser with no network requests, so the tool works offline and nothing you generate leaves your machine.

What is the Docker Tag Generator?

Free Docker image tag generator. Build valid tag strings that combine semver versions, short git-hash identifiers, environment suffixes and timestamps. Useful for testing container registry tooling and scripting CI tag conventions in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Docker Tag Generator

Name: Docker Tag Generator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Build tags your registry will accept

The Docker Tag Generator produces image tag strings that follow Docker’s tag grammar and common CI conventions. Pick a style — semantic version, short git hash, the two combined, or a timestamp — add an optional environment suffix, and get tags you can drop straight into a docker build -t command or a pipeline script.

How it works

Docker restricts a tag to letters, digits, underscores, periods and hyphens, with a 128-character limit and no leading period or hyphen. The generator builds each tag from those characters only. A semver core is MAJOR.MINOR.PATCH; a git-style identifier is a seven-character lowercase hex string mimicking an abbreviated commit SHA; a timestamp is a sortable YYYYMMDD-HHMM stamp.

The combined version-sha style joins a release with its source commit (for example 1.4.0-a1b2c3d) so the tag is both readable and immutable. An optional environment suffix such as -staging records the build target. Because mutable tags like latest defeat reproducible deploys, the tool deliberately produces immutable, content-anchored tags instead.

Tag styles and when to use each

Style	Example output	Best for
`semver`	`2.0.1`	Release builds with formal version bumps
`git-sha`	`a1b2c3d`	Per-commit CI builds where every push is unique
`version-sha`	`2.0.1-a1b2c3d`	Release builds that also need source traceability
`timestamp`	`20260606-0300`	Nightly or continuous builds with no version bump
`timestamp-sha`	`20260606-0300-a1b2c3d`	Nightly builds that also need commit traceability

Add an environment suffix (-dev, -staging, -prod) to record where the image was promoted.

Why immutable tags matter

The latest tag is mutable: it points to whatever image was pushed last. If two services depend on myapp:latest and you push a new build, both services are now running different code than what was tested — a silent, hard-to-diagnose inconsistency. Immutable tags like 2.0.1-a1b2c3d ensure:

A deployment manifest that specifies this tag will always run the same image
Rolling back is as simple as reverting the tag reference in the manifest
Audit logs show exactly which commit was running in production at any point in time

This is why Kubernetes best practices, Helm chart conventions, and most CD tools recommend against relying on latest in anything other than a local dev workflow.

Worked example for a CI pipeline script

A typical CI job might produce tags like this (the hashes and versions here are illustrative):

VERSION="1.4.0"
SHA="$(git rev-parse --short HEAD)"  # e.g. a1b2c3d in a real repo

docker build -t myregistry/myapp:${VERSION}-${SHA} .
docker push myregistry/myapp:${VERSION}-${SHA}

The generator produces the ${VERSION}-${SHA} portion so you can prototype the naming convention and test how it looks in registry UIs and deployment manifests before wiring it into a real pipeline.

Tips

Keep tags lowercase by convention even though uppercase is technically allowed — many tools and humans expect it.
All hashes and stamps are synthetic; never treat a generated tag as a real build artifact.
Nothing is sent to a server — all generation happens in your browser.