File Metadata Editor Guide: PNG Text Metadata and Sidecar JSON

Metadata is useful when a file needs context that is not obvious from the filename alone. A screenshot might need a title, a creator name, copyright notes, keywords, or a source URL. A document shared with a team might need a short description and usage note.

The hard part is that browser-based tools cannot safely rewrite every file format. Some metadata is stored inside the file, some belongs to the operating system, and some formats use complex containers. A practical metadata workflow should make that limit clear instead of pretending every file can be edited the same way.

What the editor changes

The File Metadata Editor can write embedded text metadata into PNG files. PNG supports textual chunks such as tEXt and iTXt, which are designed for fields like title, author, description, copyright, source, keywords, and comments.

When you load a PNG, the editor reads existing text metadata where possible, fills matching fields, removes old PNG text chunks, and writes a fresh set of uncompressed iTXt chunks before the final IEND chunk. The image pixels are not decoded or recompressed, so the visual content stays untouched.

When to use a sidecar file

For PDFs, Office documents, archives, videos, and many other formats, browser-side metadata editing is not reliable without a format-specific writer. In those cases, the editor creates a sidecar JSON file instead. A sidecar keeps metadata next to the original file without modifying the original bytes.

• Use embedded PNG metadata when the metadata should travel inside the PNG itself.
• Use sidecar JSON when the file format is not supported for safe embedded editing.
• Keep the sidecar filename close to the original, for example image.metadata.json.
• Store project notes, source URLs, usage rights, review status, or catalog tags in the sidecar.

Privacy and local processing

The editor runs in the browser. The selected file is read locally, and the output is generated locally. This is useful when a file contains private client context, unpublished screenshots, internal notes, or draft assets that should not be uploaded to a third-party server for a simple metadata edit.

Browsers also hide some filesystem details by design. They do not expose full local paths, hidden OS metadata, or all extended attributes. That privacy boundary is a feature, but it also means a web tool should focus on file bytes and explicit fields you choose to add.

Simple metadata rules

Good metadata is short, consistent, and easy to search later. Use a stable creator name, write a description that explains the file's purpose, and keep keywords predictable. If copyright or licensing matters, add it before sharing the file rather than relying on a folder note that may be separated later.

For shared assets, treat metadata as a small record of intent: who made it, where it came from, what it is for, and what restrictions apply. That is enough to prevent many future cleanup questions.