SumatraPDF Command-Line Printing Not Working: How to Fix It

When SumatraPDF command-line printing is not working, the cause is usually one of a few specific problems: an incorrectly quoted printer or file path, an unavailable printer, an invalid print-setting token, an unsupported or restricted source document, or a difference between the environment used for testing and the environment running the automation. The fastest approach is to reduce the command to one known PDF and one known printer, confirm the basic print path, and then restore optional settings one at a time. This guide focuses on automated printing with command-line flags, not interactive printing through Ctrl+P.

1. Confirm the Symptom With One Simple Test

Before changing SumatraPDF settings, printer drivers, or scripts, determine whether the failure follows the document, the printer, or the command. Use a small, ordinary PDF that opens correctly and does not require a password. Choose a local or reliably connected printer whose exact Windows name you can verify.

1.1 Test the default printer first

Open Command Prompt and run a minimal command using full paths. Replace the example locations with the actual locations on your computer:

"C:\Program Files\SumatraPDF\SumatraPDF.exe" -print-to-default "C:\PrintTests\sample.pdf"

The -print-to-default flag sends the document to the current Windows default printer. Quotation marks are essential when an executable or document path contains spaces.

Success means the job appears in the expected printer queue and prints normally. Once that happens, stop changing general SumatraPDF or Windows settings. The basic printing route works, so the problem is probably in the original printer selection, document, print settings, or automation environment.

If no job appears, confirm that the PDF opens in SumatraPDF and that Windows currently has a valid default printer. A default printer seen in your interactive Windows session may not be the default printer available to a scheduled task, service account, remote session, or different user.

1.2 Test one explicitly named printer

Next, copy the printer's exact name from Windows Settings, Control Panel, or PowerShell and use it with -print-to:

"C:\Program Files\SumatraPDF\SumatraPDF.exe" -print-to "Office Laser Printer" "C:\PrintTests\sample.pdf"

Always quote a printer name containing spaces, punctuation, a server path, or a shared-printer name. Do not substitute a friendly nickname used by another application. SumatraPDF must be able to resolve the printer through Windows.

Success means the test PDF reaches that specific queue. If default printing works but named printing does not, concentrate on the printer name and its availability rather than resetting the whole application.

1.3 Separate application launch failures from printing failures

If Windows reports that SumatraPDF cannot be found, the problem occurs before printing begins. Locate the executable and use its full path. Installed copies are commonly placed under a Program Files directory, while portable copies can be stored elsewhere. Do not assume the current working directory contains the executable.

If SumatraPDF starts but reports that the input file cannot be opened, verify the full document path, extension, access permissions, and quoting. If the print job reaches the queue but stalls or errors there, investigate the printer, driver, port, or spooler rather than repeatedly editing the SumatraPDF command.

2. Check the Command and Print Flags Directly

A command can look correct while being parsed differently from what its author intended. This is especially common in batch files, scheduled tasks, PowerShell scripts, and applications that construct argument strings.

2.1 Choose the correct printer flag

• -print-to-default uses the Windows default printer visible to the process.
• -print-to "Printer Name" targets a named Windows printer.
• -print-dialog opens a print dialog instead of performing fully unattended printing.

For automation, use either -print-to-default or -print-to. Do not add -print-dialog when the job must run without user interaction. A dialog can remain hidden behind another window or become inaccessible in a noninteractive scheduled task.

If the wrong printer receives the job, replace -print-to-default with -print-to and supply the verified printer name. Conversely, if named-printer selection fails, test -print-to-default to determine whether printing itself still works.

2.2 Quote printer names and file paths independently

The printer name and document path are separate command-line arguments. Each value containing spaces must have its own quotation marks:

"C:\Tools\SumatraPDF.exe" -print-to "Accounts Room Printer" "C:\Incoming Files\March Invoice.pdf"

A common mistake is placing one pair of quotation marks around multiple arguments or leaving the PDF path unquoted. The resulting pieces can be interpreted as separate filenames or options.

When a script changes its working directory, relative paths can also point somewhere unexpected. Use absolute paths during troubleshooting. Success means the same command works regardless of the directory from which it is launched.

2.3 Remove print settings, then restore them gradually

The -print-settings option can specify choices such as page ranges, orientation, color mode, duplex behavior, paper selection, or scaling. The available syntax and the printer's ability to honor a choice are separate concerns. A valid request may still be unsupported by a particular driver.

Start without -print-settings:

"C:\Tools\SumatraPDF.exe" -print-to "Office Laser Printer" "C:\PrintTests\sample.pdf"

If that works, add only one documented token or setting at a time. For example, test a simple page range before combining it with duplex, paper-bin, orientation, or color options. Separate multiple settings according to the syntax in the official command-line documentation.

Do not guess token names based on another PDF reader. Check SumatraPDF's current documentation for accepted values. Also check the target printer's preferences because duplex units, paper bins, paper sizes, and color capabilities vary by driver.

Success means the job prints after a particular option is removed or corrected. At that point, stop resetting unrelated preferences. The isolated option or driver capability is the relevant fault.

2.4 Understand silent mode and print dialogs

The -silent option suppresses certain user-facing error messages. It does not repair an invalid path, create a missing printer, or make an unsupported document printable. During diagnosis, remove -silent so that visible errors are not hidden. Restore it only after the command works reliably.

The -print-dialog option is intended for a workflow where a person can interact with the print dialog. It is not a substitute for -print-to in unattended automation. If a scheduled task appears to hang, check whether a dialog-producing option was included.

2.5 Capture the process exit code

Automation should record SumatraPDF's process exit code as well as its standard output, standard error, start time, executable path, document path, and selected printer. A nonzero exit code indicates that the process did not complete normally, but the exact interpretation should come from the documentation and behavior of the SumatraPDF build you are running.

An exit code alone does not prove that paper came out of the printer. Once a job has been submitted to Windows, a later paper, port, spooler, or device failure may occur outside SumatraPDF. Treat process completion and successful physical printing as two different checkpoints.

3. Check Windows, the Document, and External Dependencies

If the minimal command remains unsuccessful, inspect the factors immediately surrounding the print operation. Avoid reinstalling software until you know whether SumatraPDF can open the file and Windows can accept a job for the printer.

3.1 Verify the printer name and queue state

Confirm that the printer is installed for the same Windows account running the command. Open its queue and clear or resolve paused, offline, or errored jobs. Print a Windows test page if possible. If a test page fails, SumatraPDF is not the primary problem.

Network printers can be installed per user. A script launched manually may see a shared printer that a service account cannot see. Scheduled Task settings such as the selected user, whether the task runs when the user is logged off, and privilege level can therefore change printer visibility.

If SumatraPDF reports that the printer is not found, recopy its exact Windows name. For a shared printer, verify whether Windows exposes it as a friendly installed name or a UNC-style name, then use the form shown for the account running the task.

3.2 Test the source document independently

Open the same file directly in SumatraPDF. Check whether every page renders and whether the application reports a password, corruption, unsupported content, or another opening error. Do not attempt to bypass DRM, passwords, or printing restrictions. Obtain an unrestricted, authorized copy from the document owner when necessary.

Then test a small known-good PDF. If the PDF prints but the original file does not, the command and printer are probably functional. Focus on the original format, file integrity, permissions, or rendering requirements.

SumatraPDF supports several document families, but command-line printing behavior can depend on the format and the components required to render it. PDF is the best baseline test. For PostScript-related input or another format that relies on an external component in your setup, verify that the relevant dependency, such as Ghostscript, is correctly installed and accessible. Do not install extra software merely because printing failed; do so only when the source format actually requires it.

3.3 Compare installed and portable execution

An installed SumatraPDF copy and a portable copy can use different executable locations and settings locations. A script may call an older portable executable while you manually test a newer installed one. Use Task Manager, script logs, or the explicit executable path to establish which copy runs.

For a controlled comparison, call each executable by its complete path with the same PDF and printer. Do not rely on file associations or the Windows PATH value. File associations determine what opens when a document is launched through Windows, but they are unnecessary when the command explicitly invokes SumatraPDF.exe.

3.4 Check permissions and automation context

The account running SumatraPDF needs permission to read the source file and access the printer. Files on mapped drives are a frequent problem because drive letters created in an interactive session may not exist in a scheduled or elevated context. Use an accessible local test file first. For network storage, consider a properly authorized UNC path and verify access under the actual automation account.

Also ensure that the process can access its temporary directory and any location where its settings are stored. Security software, controlled folder access, or restrictive service permissions can prevent normal file access even when the command is syntactically correct.

3.5 Update or isolate the printer driver

If one printer fails while another works, inspect the failing printer's driver and queue. Try the manufacturer's supported driver or an appropriate Windows-provided driver, depending on the device administrator's policy. A driver problem is especially likely when the job enters the queue and then disappears, remains stuck, or fails only with duplex, paper-bin, color, or custom-size settings.

Success means the same minimal SumatraPDF command works after selecting a healthy queue or correcting the driver. There is no reason to delete SumatraPDF settings when the failure is isolated to one Windows printer.

4. Inspect or Reset SumatraPDF-settings.txt Safely

SumatraPDF stores persistent preferences in a settings file named SumatraPDF-settings.txt. Its location can differ depending on whether the program is installed or used in portable mode. Settings persistence matters when command behavior changes between user accounts, executable copies, or repeated runs.

4.1 Back up before editing

Close SumatraPDF completely. Locate the settings file used by the exact executable and account involved, then copy it to a safe backup name. Do not edit or delete every settings file you find, because another SumatraPDF installation or Windows user may use it.

Open the file in a plain-text editor and look for printer-related or path-related values that clearly correspond to the symptom. Avoid speculative edits to unfamiliar entries. Command-line arguments should control the requested automated print operation, but persistent state can still help explain differences between environments.

4.2 Reset by renaming rather than deleting

To perform a reversible reset, rename the file while SumatraPDF is closed, such as:

SumatraPDF-settings.txt to SumatraPDF-settings.backup.txt

Start SumatraPDF again so it can create fresh settings, then repeat the minimal PDF and printer test. If printing begins working, compare the backup with the new file carefully. Restore only settings you understand instead of copying the entire old file back immediately.

If resetting the file changes nothing, restore the backup and move on. Repeatedly deleting settings will not correct a missing document, inaccessible printer, malformed command, broken driver, or unavailable dependency.

5. Run a Clean Temporary Test Before Reinstalling

A clean test helps distinguish application state from machine-wide printing problems. Create a temporary folder with a known SumatraPDF executable you trust and a small known-good PDF. Use a short local path without unusual characters, such as C:\SumatraTest.

1. Close all SumatraPDF processes.
2. Place or identify the test executable and PDF.
3. Confirm the selected printer can print a Windows test page.
4. Run the command without -silent, -print-dialog, or -print-settings.
5. Use -print-to-default first.
6. Repeat with -print-to and the exact quoted printer name.
7. Record the exit code and inspect the Windows printer queue.

If this clean test works, do not reinstall SumatraPDF. Compare the working command with the original automation, paying attention to executable versions and locations, current directories, quoting, account identity, mapped drives, source formats, and added print settings.

If the clean test fails with multiple known-good PDFs and multiple working printers, then replacing or reinstalling the application becomes more reasonable. Preserve settings and scripts before doing so. Reinstallation should follow evidence, not replace basic command and printer verification.

6. Quick Fix Checklist

• Test one small, unrestricted PDF before testing eBooks, comics, images, XPS, DjVu, CHM, or other formats.
• Confirm that the PDF opens and renders correctly in SumatraPDF.
• Use the full path to SumatraPDF.exe.
• Use the full path to the source document.
• Quote every path and printer name containing spaces.
• Test -print-to-default before selecting a named printer.
• Copy the exact Windows printer name for -print-to.
• Remove -print-settings, then add documented settings individually.
• Remove -silent while troubleshooting so errors remain visible.
• Do not use -print-dialog for unattended printing.
• Check the printer queue and print a Windows test page.
• Run the test under the same user account as the real automation.
• Replace mapped-drive paths with accessible local or authorized network paths.
• Compare installed and portable executable paths.
• Back up and rename SumatraPDF-settings.txt only when persistent state is a plausible cause.
• Stop changing settings as soon as the minimal command succeeds, then restore options one at a time.

7. Frequently Asked Questions

7.1 Why does -print-to-default use the wrong printer?

It uses the Windows default printer available to the process and user account running SumatraPDF. Another user, a scheduled task, or a service account may have a different default. Use -print-to with the exact quoted printer name when printer selection must be deterministic.

7.2 Why does SumatraPDF say the printer was not found?

The name may not exactly match an installed Windows printer, or the printer may not be installed for the automation account. Verify the name in Windows under that account. Check spacing, punctuation, shared-printer naming, and whether the network printer is currently connected.

7.3 Can -silent cause printing to fail?

The option does not normally create the underlying failure, but it can hide information that would identify it. Remove -silent during troubleshooting. Add it back only after the command, file, printer, and optional settings have been validated.

7.4 Why does the command work manually but fail in a scheduled task?

The task may use a different account, working directory, default printer, network access token, mapped-drive configuration, or desktop interaction mode. Use absolute paths and test access to both the file and printer under the task's actual identity. Avoid -print-dialog because unattended tasks cannot reliably interact with dialogs.

7.5 What does a successful exit code prove?

It indicates that the SumatraPDF process completed without reporting a process-level failure according to its implementation. It does not guarantee that the printer physically produced the pages. Monitor the Windows queue or printer management system when delivery confirmation matters.

7.6 When should I stop troubleshooting SumatraPDF itself?

Stop changing SumatraPDF when a known-good PDF reaches one printer through a minimal command. If only one document fails, investigate that document or format. If only one printer fails, investigate its Windows queue, driver, port, or capabilities. If only the script fails, compare its quoting, paths, account, working directory, and arguments with the successful manual command.