Introduction

Encoding errors in Python source files usually appear when the file contains characters outside plain ASCII and the interpreter guesses the wrong source encoding. The message often looks confusing because the actual problem is not the text itself. The problem is that Python needs to know how to decode the bytes in the file before it can parse the code.

Why This Error Happens

A source file on disk is just bytes. Before Python can execute it, it must decode those bytes into characters.

In modern Python 3 projects, UTF-8 is the normal answer. But older scripts, editor defaults, copied text from documents, or mixed-platform tooling can produce files that are not saved as UTF-8. When that happens, Python may raise errors such as:

• 'SyntaxError: Non-ASCII character ...'
• 'SyntaxError: Non-UTF-8 code starting with ...'

This is especially common when the file includes accented text, smart quotes, em-space characters, or non-English comments copied from another source.

The Correct Fix in Python 3

The best fix is usually simple: save the file as UTF-8.

If your editor is already using UTF-8, this script works normally:

message = "café"
print(message)

Most editors today default to UTF-8, so Python 3 handles this without extra configuration. If you still get an encoding-related syntax error, inspect the editor's actual file encoding rather than assuming what it saved.

Declaring the Encoding Explicitly

If you need to be explicit, add an encoding declaration at the top of the file. This is especially useful for compatibility with older tooling and for making the file's intent obvious to other developers.

1# -*- coding: utf-8 -*-
2
3message = "Olá, mundo"
4print(message)

Place that declaration on the first or second line of the file. It tells the interpreter how to decode the source itself.

Even in Python 3, this can be useful when the project contains legacy files or build steps that manipulate source files in inconsistent ways.

Python 2 Versus Python 3

A lot of older discussions about this error come from Python 2, where ASCII assumptions were much more visible. In Python 2, using non-ASCII characters without an encoding declaration often failed immediately.

Python 3 improved the situation by making Unicode the default model for text in code. But Python 3 still cannot parse a file correctly if the bytes on disk are not valid UTF-8 and no correct encoding declaration exists.

That means two separate questions matter:

1. What encoding is the file actually saved in?
2. What encoding does Python think the file uses?

If those answers differ, the script fails before runtime.

How to Diagnose the Real Problem

If a file looks normal in one editor but Python rejects it, there may be hidden characters or a mismatched save encoding. A useful debugging step is to isolate the suspicious line and retype it manually instead of copy-pasting it.

For example, these visually similar quote characters are not the same:

1# good
2name = "resume"
3
4# bad if copied as smart quotes into source
5# name = “resume”

Smart quotes are common when code is copied from a word processor, chat client, or formatted website. Python does not treat them as string delimiters.

Reading and Writing Text Safely

Source encoding issues are separate from file I/O encoding issues, but the two are often confused. Even if the source file is valid UTF-8, you should still open text files with an explicit encoding when reading or writing data.

1text = "naïve café"
2
3with open("sample.txt", "w", encoding="utf-8") as handle:
4    handle.write(text)
5
6with open("sample.txt", "r", encoding="utf-8") as handle:
7    print(handle.read())

This does not fix a broken source file, but it prevents another class of encoding bugs in your program.

Editor and Tooling Settings Matter

Different editors expose encoding in different ways. If you work across Windows, macOS, and Linux, verify that the project uses UTF-8 consistently. A repository can look fine until one file is saved in a local code page and committed.

Practical safeguards include:

• configure the editor to save Python files as UTF-8
• avoid copy-pasting code from rich-text sources
• use linting or pre-commit checks to catch malformed files early
• review suspicious diffs for invisible character changes

In teams, this is a tooling discipline problem as much as a Python problem.

Common Pitfalls

The biggest mistake is adding the UTF-8 coding comment without actually saving the file as UTF-8. The declaration does not magically convert the bytes already on disk.

Another common issue is confusing source encoding with string encoding at runtime. A script can parse correctly and still mishandle file input or terminal output if I/O encodings are wrong.

Be careful with smart quotes, copied dashes, and invisible whitespace from formatted documents. Those characters can break parsing even though the line looks normal.

Finally, do not assume every error mentioning non-ASCII means the text content is invalid. Often the text is fine and the editor simply saved the file with the wrong encoding.

Summary

• Python must decode source bytes before it can parse a script.
• The safest default for Python source files is UTF-8.
• Save the file as UTF-8 and, when helpful, add # -*- coding: utf-8 -*-.
• Python 3 handles Unicode text well, but only if the file encoding is correct.
• Source encoding problems are different from runtime file I/O encoding problems.
• Smart quotes and copied rich-text characters are common hidden causes.