Skimmark / Blog

What is a byte-for-byte round-trip save?

Bobby Huang ·

A byte-for-byte round-trip save means that when you open a file and save it without changing anything, the bytes on disk come out exactly the same as before, and when you do edit, only the bytes you changed are different.

Key takeaways

  • A round-trip save keeps the diff the size of your edit.
  • Files can render the same while differing in line endings, trailing spaces or the final newline.
  • Compare an unchanged save byte for byte with cmp on macOS or Linux, or fc /b on Windows.
  • Skimmark is in development and not released; its Round-Trip save is planned for v1.

A byte-for-byte round-trip save means that when you open a file and save it without changing anything, the bytes on disk come out exactly the same as before, and when you do edit, only the bytes you changed are different.

The plain version

Open a Markdown file. Fix one typo. Save. Now run a diff. If the save was a true round trip, the diff shows one line: your typo fix. Nothing else moved.

That sounds like the obvious default. It often isn't. Some tools read Markdown into a model, then write the model back out. On the way out they can change things you never touched:

  • list markers (* becomes -)
  • emphasis style (_word_ becomes *word*)
  • blank lines and indentation
  • line endings (CRLF becomes LF)
  • the final newline at the end of the file
  • a byte order mark at the very start

Each of those is a real byte change. Your diff fills up with noise, and the one line that matters is hard to find.

Why it matters when agents write your Markdown

If an AI agent writes a file and you open it to read or fix one line, you want your save to leave the agent's work alone. A noisy save causes three problems:

  1. Git diffs get large. A one-word fix shows up as a whole-file rewrite.
  2. Review gets harder. You can't tell your change from formatting churn.
  3. Merges conflict. If the agent edits the file again, both versions touched every line.

A round-trip save keeps the diff the size of your edit.

What "byte-for-byte" covers

The term is strict on purpose. It is not "looks the same when rendered." Two files can render the same and still differ in line endings, trailing spaces or a missing final newline. A byte-for-byte save keeps all of those as they were.

How to check a tool yourself

  1. Copy a Markdown file that uses CRLF line endings and has no final newline.
  2. Open it in the tool, make no change, and save.
  3. Compare the two files byte for byte (cmp on macOS or Linux, fc /b on Windows).

No output from cmp means the round trip held.

Where Skimmark fits (planned for v1)

Skimmark is a Markdown reader and editor for people whose AI agents write Markdown. It is in development and not released. Its save is planned for v1 to work this way, per the app's help docs:

  • Line endings, including Windows-style CRLF, a missing final newline, and a byte order mark are kept as they are.
  • Before it writes, it checks the file on disk is still the version you opened. If an agent changed it, it doesn't save, and you choose Keep mine or Load theirs.
  • It writes to a hidden temp file and swaps it in, so a crash leaves either the old file or the new one, never a mix.

Related terms

  • Line diff: a diff that compares files line by line, the way git does.
  • Rendered diff: a diff of the formatted output, which hides byte-level changes.
  • Atomic save: a save that replaces the file in one step, so it is never half-written.

Next read

Seeing what changed in a Markdown file: git, diff tools, and readers covers the wider diff workflow.

Skimmark is in development. Skimmark is the home page.

View as Markdown