Fix mixed encodings in a payroll CSV

A payroll CSV can look fine in some rows and show broken characters in others. Names such as García may appear as García, or a replacement character may show up where a letter should be. That is often an encoding problem, but changing the file's encoding at random can make correct text worse.

Use the CSV Editor to inspect a working copy, locate the affected cells, and make verified corrections. For a payroll handoff, keep the original untouched and check employee counts and payment totals before sending anything.

Inspect the CSV safely

1. Make a copy of the payroll CSV first. Open the copy in the CSV Editor, which can open large CSV files in your browser.
2. Check a few affected rows and a few rows that look correct. Look at names and addresses, but also confirm that employee IDs, dates, and amount columns still appear in the right places.
3. Use the editor's find function to look for a visible replacement character, �, or a repeated pattern such as Ã. Compare any suspicious result with the same employee's trusted record in the payroll system or original source.
4. Decide whether the problem affects the whole file, only certain rows, or only a few cells. Do not make bulk replacements until you know which characters are wrong and what they should be.

The CSV Editor lets you inspect and edit data, but it is not an encoding detector or a guaranteed encoding converter. Treat it as a way to review and correct verified cell contents, not as a way to guess how the file's bytes should be read.

What the result means

Names show patterns like García

This often means text encoded as UTF-8 was read using a different encoding, such as Windows-1252. The file may contain the correct original bytes, but the program that opened it interpreted them incorrectly. Reopen or export it with the correct encoding at the source, rather than replacing every Ã by hand.

Some rows look right and others look corrupted

A single file is normally read using one encoding. If some rows are fine and others are not, the rows may have been combined from different exports, or the bad text may already have been misread and saved earlier. A whole-file encoding change could fix one group while breaking another. Compare the affected values with their authoritative records.

A replacement character appears

The character � can appear when software could not decode a byte sequence and substituted a placeholder. If the file was saved after that substitution, the original character may no longer be recoverable from this copy. Get a fresh export from the system that owns the employee data.

Columns shift or amounts appear in the wrong fields

This may be a delimiter or quoting problem, not an encoding problem. CSV files can use commas, semicolons, or other separators, and a comma inside a quoted name or address should remain part of that field. Compare the column layout with a known-good export before changing text.

How to fix it

1. Keep the original file unchanged. Work from a duplicate and give the corrected copy a different name. That gives you a way back if a repair changes names, IDs, dates, or amounts unexpectedly.
2. Export a fresh copy from the source system. If the payroll or HR system offers an encoding choice, choose UTF-8 and confirm that the export completes successfully. If you cannot find an encoding option, ask the system's support team which format it uses and how to export text reliably.
3. Check whether the source already contains broken text. Compare a problem name in the payroll system with the fresh export. If the source itself displays the corrupted spelling, fix the employee record there first, then export again. Editing only the handoff file can leave the underlying record wrong.
4. Correct only values you can verify. If a small number of cells are wrong and you have an authoritative reference, edit those cells in the CSV Editor. Avoid a global replace: the same character sequence may be valid in another employee's name or in a different field.
5. Recheck payroll data before sending. Compare the number of employee rows and the totals for the same pay period against the source report. Check a sample of IDs, dates, and amounts, and confirm that columns have not shifted. If any total differs, stop the handoff and trace the change before sharing the file.

Why mixed encodings are hard to repair

CSV describes how fields and rows are separated, but it does not guarantee one universal text encoding. In ordinary use, a file is decoded consistently from beginning to end. When records from different sources are appended, or text is decoded incorrectly and saved, some characters can be damaged while others remain readable. That is why a single encoding change may not repair every row.

For a few confirmed misspellings, a careful cell edit may be enough. For many affected rows, a fresh export from the original system is safer than trying to reconstruct each name. Avoid passing payroll data through unrelated conversion tools or sharing it with someone who does not need access.

The CSV Editor processes the file in your browser, and files stay on your device.