Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Documentation | 2026.1

# p4 tag

Tag files with a label.

## Syntax

    p4 [g-opts] tag [-d -g -n -U] -l labelnameFileSpec[revSpec]

Syntax and naming conventions

## Description

Use `p4 tag` to tag specified file revisions with a label. A labelname is required. If a label named `labelname` does not exist, it is created automatically. If the label already exists, you must be the `Owner:` of the label and the label must be `unlocked` in order for you to tag or untag files with the label. (Use `p4 label` to change label ownership or lock status.)

If the `file` argument does not include a revision specification, the head revision is tagged with the label. If the file argument includes a revision range specification, only files with revisions in that range are tagged. (If more than one revision of the file exists in the specified range, the highest revision in the specified range is tagged.)

## Options

Option | Description
--- | ---
`-d` | Delete the association between the specified files and the label, regardless of revision.
`-g` | In multi-server environments, use the `-g` option to specify whether the label being applied is local to an Edge server, or is globally available from the Commit server. Global labels can be updated from edge servers using either p4 tag -g or p4 labelsync -g To learn more, see "Setting global client views" under Client workspaces and client views.
`-l labelname` | Specify the label to be applied to file revisions
`-n` | Display what `p4 tag` would do without actually performing the operation.
`-U` | If tagging files with a new label, set the `autoreload` option of the newly-created label. This option has no effect when used with an existing label.
`g-opts` | See Global options.

## Usage Notes

Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required
--- | --- | ---
Yes | Yes | `list`

- By default, `p4 tag` operates on the head revision of files in the depot. To preserve the state of a client workspace, use `p4 labelsync`, which operates on the revision of files last synced to your workspace.

- With a multi-server Perforce service, `p4 tag` works with a label local to the edge server (to which you are sending a request). The `-g` option can be used to apply a global label, but only with an unbound (global) client workspace.

  Local Tag | Global Tag
  --- | ---
  `rpl.labels.global` is unset, which is 0 | `rpl.labels.global` set to 1
  by default, labels are local to your edge server | by default, labels are global
  `-g` option provides access to global labels on the commit server | `-g` option allows the updating of local labels If a label exists on an edge server before rpl.labels.global is set, and you want that label to be available on both the edge server and the commit server, unloaded the label from the edge server and reload it on the commit server

## Examples

`p4 tag -l rel1 //depot/1.0/...` | Tag the head revisions of files in `//depot/1.0/...` with label `rel1`. If the label `rel1` does not exist, create it.
`p4 tag -l build //depot/1.0/...@1234` | Tag the most recent revisions as of the submission of changelist `1234` of files in `//depot/1.0/...` with label `build`. If the label `build` does not exist, create it.
`p4 files @labelname` | List the file revisions tagged by `labelname`.

## Related commands

To create or edit a label | `p4 label`
To list all labels known to the system | `p4 labels`
To tag revisions in your client workspace with a label | `p4 labelsync`

Your search for returned results