How to Read an Error Message and Pass It to AI

September 8, 2026

An error message is the program telling you what went wrong, and you do not need to understand all of it. The useful parts are the type of error, a short description, and a file name with a line number. Copy the whole message exactly as it appears and paste it to your AI assistant along with the code, and you will usually get a precise fix.

This guide shows where to find error messages in a browser and how to pick out the parts that matter.

Where errors appear

For web tools, the most important place is the browser console. To open it:

1. Open your page in Chrome, Edge, Firefox or Safari.
2. Right-click anywhere on the page and choose Inspect (in Safari, enable the Develop menu in settings first).
3. Click the Console tab.

Red lines are errors. Yellow lines are warnings, which are usually less urgent. If the console is empty, either no error occurred or you opened it after the problem. Reload the page with the console open and try again.

The anatomy of an error message

Most messages follow a pattern. Take this example:

Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
    at index.html:42

Break it into parts:

• Uncaught TypeError is the kind of problem. A TypeError means the code tried to use something in a way that does not fit its type.
• Cannot read properties of null (reading ‘addEventListener’) is the description. Here, the code tried to attach a listener to something that does not exist, which is null.
• index.html:42 is the location: file index.html, line 42.

Without knowing any programming, you can read this as: on line 42, the code looks for something on the page and does not find it. That is a very common beginner situation, often caused by a mismatched name or a script running before the page has loaded.

Common messages in plain words

Some messages you are likely to meet:

• “X is not defined”: the code uses a name that does not exist. A typo, a missing library or a missing piece of code is likely.
• “X is not a function”: the code tries to run something that is not runnable. Perhaps the name is wrong, or a library did not load.
• “Unexpected token”: there is a syntax slip, such as a missing bracket, comma or quote.
• “Failed to load resource”: the page tried to get a file and could not.
• “Cannot read properties of undefined”: the code expected data that is not there yet.

You do not need to fix these yourself. Understanding their general meaning helps you describe the problem better.

Which line to copy

If the console shows many errors, scroll to the top and start with the first one. Later errors are often side effects of the first. Fixing the first may clear the rest.

Copy the entire line, including the file name and number. If the message spans several lines, include them all. Avoid taking a screenshot only; text is easier for the assistant to work with, and you can add the screenshot as an extra.

What to send with it

A complete request has four parts:

1. The exact error text.
2. The relevant code, or the whole file if it is small.
3. What you did just before it appeared.
4. What you expected to happen.

For instance: “I clicked Add and nothing happened. The console shows: [error]. Here is my file. I expected a new task to appear.” With this, the assistant can connect the error to a line and to a symptom.

Ask for an explanation along with the fix: “Explain what caused this in one or two sentences.” Over time, those explanations teach you to spot the causes yourself.

What if there is no error

Some problems produce no message. The page loads, nothing breaks, and the result is wrong. In those cases, add visibility. Ask the assistant: “Add temporary messages that print the key values at each step, so I can see where the numbers go wrong.” These show up in the console, and you can paste them back for analysis. Remove them when the bug is fixed.

Warnings versus errors

A warning means the code ran, but something looks questionable. An error means something failed. Beginners often panic at long lists of warnings and ignore the one error hidden among them. Filter the console to show only errors if your browser offers that option, and handle those first.

Warnings still deserve a glance. If a page behaves oddly and the console shows a warning about a missing file or a deprecated feature, it may be a clue. Paste it to the assistant with the symptom and ask whether it is related. Often the answer is no, and then you can ignore it with confidence.

Errors that appear outside the browser

If you run scripts on your computer, errors show up in a terminal window. The same principle applies. Copy the full text, including the line that starts with “Traceback” or “Error.” Include the command you ran and what the script was supposed to do. Do not run commands you do not understand; ask the assistant what a command does first.

Avoid these habits

Do not paraphrase the message. Small words matter. Do not paste only the last line if there is more above it. Do not ask for a rewrite when a message points to one line. And do not ignore warnings when a project stops behaving, since sometimes they hint at the cause.

Next step

Open the console on any web page you have built and read what is there. Even a working page may show a warning. Practice naming the error type, the description and the location. Then create a mistake on purpose, like deleting a closing bracket in a copy of your file, reload, and see how the message points to it. Seeing a cause and its message together makes the next real error much less intimidating.