SumatraPDF Forward Search Not Working: How to Fix It

When SumatraPDF forward search is not working, your LaTeX editor may compile the document successfully and open the correct PDF, yet SumatraPDF does not move to or highlight the corresponding text. This usually points to one of four causes: the compiler did not generate usable SyncTeX data, the editor is sending an incorrect command, the source and PDF paths do not match the files used during compilation, or SumatraPDF's instance and highlighting settings are interfering. The steps below focus specifically on editor-to-PDF forward search, not inverse search from the PDF back to your editor.

1. Confirm the Symptom With One Simple Document Test

Before changing application settings, determine whether the problem affects every LaTeX project or only one document. A minimal test separates a general integration problem from project-specific issues involving build folders, stale output, unusual file names, or included source files.

1.1 Create a minimal LaTeX document

Create a new folder with a short, uncomplicated path, such as C:\LaTeXTest. Save the following content as test.tex:

\documentclass{article}
\begin{document}
First test paragraph.

Second test paragraph for forward search.
\end{document}

Compile it with SyncTeX enabled, then place the cursor on the second paragraph and run your editor's forward-search command. Avoid custom build scripts, multiple source files, cloud-synchronized folders, and output-directory options for this first test.

Success means SumatraPDF opens test.pdf, moves to the second paragraph, and briefly displays a highlight near that location. If this works, stop changing global SumatraPDF settings. The original project probably has a path, build-directory, or stale-file problem. If the minimal document also fails, continue with the integration checks below.

1.2 Verify that the PDF was actually rebuilt

A forward-search command cannot compensate for an outdated PDF. After compiling, check the modification time of the PDF and confirm that it changed. You can also add an obvious word to the document and verify that the word appears in the reopened or refreshed PDF.

If the PDF does not change, inspect the editor's compilation output. The build may have stopped on an error, written the PDF to another directory, or compiled a different root file. Fix that issue first. Success means the PDF visibly reflects the latest source and has a current modification time.

2. Check SyncTeX Generation and the Editor Command

Forward search depends on synchronization information connecting source lines to positions in the rendered PDF. SumatraPDF normally obtains that information from a SyncTeX sidecar file generated by the TeX engine. Opening a PDF by itself is not enough.

2.1 Confirm that SyncTeX is enabled

Compile with the appropriate SyncTeX option. A common command for pdfLaTeX is:

pdflatex -synctex=1 -interaction=nonstopmode test.tex

Depending on your editor and TeX distribution, SyncTeX may be enabled through a build-profile checkbox or by adding -synctex=1 to the compiler arguments. After a successful build, look for test.synctex.gz beside the PDF. Some workflows may produce an uncompressed .synctex file instead.

The base names must correspond. For example, report.pdf should normally be accompanied by report.synctex.gz. If there is no synchronization file, correct the compiler configuration and rebuild. Success means a new SyncTeX file appears and forward search reaches the expected PDF location.

2.2 Check the exact forward-search command

Your LaTeX editor must call SumatraPDF with the PDF path, source path, and current line number. A typical command has this structure:

"C:\Program Files\SumatraPDF\SumatraPDF.exe" -reuse-instance -forward-search "C:\Project\main.tex" 42 "C:\Project\main.pdf"

The editor will usually substitute placeholders for the source file, line number, and PDF file. Placeholder syntax varies by editor, so use the syntax documented by that editor rather than copying placeholders from another program.

Verify these details:

• The path to SumatraPDF.exe points to the executable you actually use.
• -forward-search is followed by the source path and a valid line number.
• The final argument is the PDF generated by the active build profile.
• Paths that can contain spaces are enclosed in quotation marks.
• The command uses ordinary straight quotation marks rather than typographic quotes.

If practical, replace the editor placeholders temporarily with real paths and a line number, then run the command from Command Prompt. Success means the PDF opens or comes to the foreground and the selected line is highlighted. Once the literal command works, restore the editor placeholders carefully.

2.3 Treat file names with spaces as a quoting test

Spaces are supported, but every complete path must be quoted. For example, "C:\My Documents\Thesis Project\main.tex" must be one argument. Without quotes, SumatraPDF may receive fragments such as C:\My and Documents\Thesis, preventing synchronization even when the files exist.

For diagnosis, copy the minimal test into a path without spaces. If forward search works there, repair the editor's command quoting rather than renaming every project. Stop when the same command also works with the original quoted paths.

3. Match the PDF Path, Source Path, and SumatraPDF Instance

A frequent cause of SumatraPDF troubleshooting confusion is that the editor builds one PDF but sends forward-search instructions to another copy. This can happen when output goes into a build folder, the editor uses a master document, or an old PDF remains open elsewhere.

3.1 Compare paths with the compilation log

Find the output PDF path reported by your build tool. Compare it with the PDF argument in the forward-search command. They must identify the same file. If compilation produces C:\Project\build\main.pdf, a command targeting C:\Project\main.pdf is wrong even if both files exist.

Apply the same check to the source path. In a multi-file project, the editor should send the path of the source file containing the cursor, while the PDF argument should normally refer to the compiled root document. Editors with root-document or master-file settings may require that relationship to be configured explicitly.

Success means the command points to the newly built PDF and the exact source file represented in its SyncTeX data. When those paths match and navigation works, do not alter file associations or reinstall SumatraPDF.

3.2 Use reuse-instance behavior consistently

The -reuse-instance option tells the command to reuse an existing SumatraPDF process instead of opening an unrelated window for each request. This is commonly useful for LaTeX workflows because the editor repeatedly sends navigation requests to the same viewer.

Close every SumatraPDF window, compile the document, and run forward search again with -reuse-instance included. Watch whether one window opens with the correct PDF. If several SumatraPDF installations or portable copies are present, use the full executable path so the editor always calls the intended copy.

Success means repeated forward searches reuse the expected window and move to different source locations. If navigation now works reliably, stop changing instance options.

3.3 Understand the limited role of file associations

Making SumatraPDF the default PDF reader does not create forward-search integration. The editor should ideally call SumatraPDF.exe directly with synchronization arguments. File association matters only when the editor merely asks Windows to open a PDF, which usually cannot pass the source file and line number needed for forward search.

If your editor configuration contains only a PDF path and no SumatraPDF command-line arguments, select or configure an external-viewer command that supports forward search. Success means the editor launches SumatraPDF with source and line information rather than only opening the document.

4. Check Highlighting and Relevant External Factors

Sometimes forward search reaches the correct page, but the result looks like a failure because the highlight is too brief, narrow, or difficult to see. In other cases, a build wrapper prevents fresh SyncTeX data from reaching the viewer.

4.1 Distinguish navigation failure from an invisible highlight

Test two source lines located on widely separated pages. Run forward search from each line and observe the page number in SumatraPDF. If the page changes correctly, synchronization is working even if the highlight is hard to see.

SumatraPDF's advanced settings can control the forward-search highlight color, width, offset, and whether it remains visible. Exact available settings can depend on the installed build, so edit only entries already present in your settings file or documented by SumatraPDF. A typical settings block may contain values such as:

ForwardSearch = [
    HighlightColor = #6581ff
    HighlightOffset = 0
    HighlightWidth = 15
    HighlightPermanent = false
]

Choose a contrasting color and a visible width for testing. Setting a persistent highlight can help confirm the result, but it is optional. Success means the correct region is obvious. Once visibility is confirmed, choose less intrusive values if preferred.

4.2 Focus on the TeX toolchain rather than unrelated PDF features

For a normal PDF produced by pdfLaTeX, LuaLaTeX, or XeLaTeX, forward search primarily depends on the PDF, its matching SyncTeX data, and correct paths. Printer drivers, Windows PDF associations, multimedia codecs, Ghostscript, and comic or eBook support are generally unrelated to this symptom.

Those external components become relevant only when your workflow actually uses them. For example, a custom conversion chain might copy, rename, or regenerate a PDF after TeX compilation while leaving SyncTeX behind. If you use such a workflow, temporarily compile directly to a local PDF and test before the conversion step. Never remove DRM or document restrictions to troubleshoot synchronization.

Success means direct TeX output synchronizes correctly. If so, examine the later build or conversion step instead of changing SumatraPDF's rendering settings.

5. Inspect or Reset SumatraPDF-settings.txt Safely

Settings persistence matters when SumatraPDF appears to ignore a highlight change, keeps launching with unexpected behavior, or works in one copy but not another. Installed and portable copies can use different settings locations.

5.1 Locate the active settings file

For a conventional installed copy, settings are commonly stored under the current Windows user's local application data folder, typically %LOCALAPPDATA%\SumatraPDF\SumatraPDF-settings.txt. A portable copy commonly keeps its settings near the executable when that directory is writable.

Close SumatraPDF before editing the file so the application does not overwrite your changes on exit. Confirm which executable the editor launches, then locate the settings associated with that copy. If the editor calls one installation while you manually open another, changes may appear not to persist.

5.2 Back up before editing or resetting

Copy SumatraPDF-settings.txt to a safe location. Make only one change at a time and preserve the file's structure. Do not delete unrelated options merely because forward search fails.

For a controlled reset, close SumatraPDF and rename the file to SumatraPDF-settings.backup.txt. Start SumatraPDF again so it can create fresh defaults, then repeat the minimal forward-search test. If the clean settings solve the issue, reapply only necessary preferences gradually. If they do not, restore the backup and return your attention to SyncTeX and command paths.

Success means the temporary default configuration processes forward search correctly. Stop resetting settings once the responsible option or configuration copy is identified.

6. Run a Clean Temporary Test Before Reinstalling

Reinstallation rarely repairs a missing SyncTeX file or an incorrect editor command. A clean test provides better evidence and avoids destroying a useful configuration.

1. Close all SumatraPDF windows.
2. Create a short local folder such as C:\LaTeXTest.
3. Compile one minimal test.tex file with -synctex=1.
4. Confirm that test.pdf and test.synctex.gz were created together.
5. Call the intended SumatraPDF executable with literal, fully quoted paths.
6. Repeat the command with two widely separated line numbers.

If the test works, SumatraPDF and the TeX engine are functional. Compare the working command with the failing editor profile, especially its placeholders, output directory, root-document selection, and quotation marks. If the test fails, try a fresh portable copy in a separate writable folder without replacing your installed copy. This can distinguish an executable or settings problem from an editor problem.

Reinstall only if a clean copy also behaves incorrectly despite a verified PDF, matching SyncTeX file, and correct literal command. Preserve your settings backup and note the executable path before making changes.

7. Quick Fix Checklist

• Compile with SyncTeX enabled and confirm that a matching .synctex.gz file exists.
• Verify that the PDF contains the latest source changes.
• Check that the editor sends -forward-search, the source path, line number, and PDF path.
• Quote every path that contains spaces.
• Target the PDF in the actual output folder, not an older copy.
• Use the current source file with the correct compiled root PDF.
• Call the intended installed or portable SumatraPDF executable explicitly.
• Try -reuse-instance and close stray SumatraPDF windows before testing.
• Check page movement to distinguish failed navigation from an invisible highlight.
• Back up the settings file before changing highlight options or testing defaults.
• Prove the setup with one minimal local document before reinstalling anything.

8. Frequently Asked Questions

8.1 Why does SumatraPDF open the PDF but not jump to the line?

Opening the PDF confirms only that the viewer path and PDF argument are usable. Jumping to a line additionally requires a valid source path, current line number, matching SyncTeX data, and the exact PDF represented by that data. Inspect the complete editor command and verify the build output location.

8.2 Is inverse search configuration required for forward search?

No. Forward search sends a location from the editor to SumatraPDF. Inverse search sends a location from SumatraPDF back to the editor. An inverse-search command is not required to make editor-to-PDF navigation work.

8.3 Why does forward search work in a small test but not my project?

The project probably uses a build directory, root document, included source file, custom compilation script, or stale PDF. Compare the successful test's paths with the project's compilation log. Also confirm that the project produces fresh SyncTeX data after every relevant build.

8.4 Can spaces in file names break forward search?

Spaces are valid, but unquoted paths break command-line argument parsing. Enclose the complete executable, source, and PDF paths in straight quotation marks. A temporary no-space path is useful for confirming a quoting problem.

8.5 Why does the page move without showing a highlight?

If the page changes to the correct location, forward search is functioning. The highlight may be brief, narrow, or low contrast. Inspect the forward-search highlight entries in the active settings file and temporarily choose a more visible color, width, or persistent display.

8.6 Should I reinstall SumatraPDF immediately?

No. First test a minimal document, verify the SyncTeX file, run a literal command, and identify which SumatraPDF executable is being called. Reinstalling will not correct editor placeholders, mismatched output paths, or a PDF that was never rebuilt.