Local extraction

Local extraction runs an Octoparse task on your own computer. The target website is opened and processed from your local environment, collected data is saved directly on the device, and you can watch the workflow, inspect its output, and intervene while it runs. Local extraction is available for free. It is a practical choice for testing, small-volume collection, and workflows where control over the execution environment or data location matters more than unattended scale.

Choose local extraction when you want to collect data without consuming cloud extraction resources. For 24/7 operation, large-scale collection, or runs that must continue independently of your computer, use cloud extraction.

Why run locally

Collect locally for free

You can build, test, and run tasks locally without paying for cloud extraction capacity. This makes local extraction suitable for:

Learning and evaluating Octoparse
Building and debugging new tasks
One-time or small-volume data collection
Running occasional tasks when cloud scale is unnecessary

Your own computer supplies the processing, memory, storage, power, and network connection. The absence of cloud extraction charges does not remove the operational cost of maintaining that local environment.

Direct control and visibility

A local run stays close to the task-building experience. You can observe page navigation and extraction as they happen, compare the browser with the Data Preview, pause or stop the run, and adjust the task when a selector, wait condition, login, or page action behaves unexpectedly. This makes local extraction especially useful for:

Testing a new or recently changed workflow
Diagnosing website-specific behavior
Checking missing, incorrect, or repeated values
Verifying login, pagination, scrolling, and detail-page actions
Running a small, one-time collection under direct supervision

Use your local environment

Requests originate from the network environment where Octoparse is running. The task can therefore use conditions tied to that environment, such as a local IP address, regional access, an authenticated browsing session, or access available through your organization’s network. This can help when a task works in your browser but behaves differently on a cloud node. You also retain more control over the device environment: approved supporting software, network tools, and system settings can be managed according to your workflow and organizational requirements. That flexibility comes with responsibility. Local results depend on your machine, network, browser session, installed software, and system configuration. Environment changes can affect task behavior.

Keep the active run on your device

During local extraction, task execution and collected data are handled primarily on the local device. This gives you more direct control over where extraction data is stored and can support policies that require data to remain in a user-managed environment. Exact data handling can vary by task, account, export destination, and enabled service. Local execution does not by itself guarantee privacy or compliance. Consider the complete data path:

The target website still receives requests from your network.
Signing in, syncing task configurations, sharing work, or using an online export can still transmit related information to the applicable service.
Exported data is subject to the security and access controls of its destination.
Anyone with access to the computer or local output may be able to access the collected data.

If data handling requirements are strict, confirm the task, account, export destination, device controls, and organizational policy together.

Control credentials and sessions

Local extraction can be useful for websites that rely on a session established in the desktop environment. It may reduce the need to reproduce that browsing state in a separate cloud environment. Treat login credentials and cookies as sensitive. Use an approved account, protect the device, limit access to task files and outputs, and avoid collecting data beyond what you are permitted to access.

Recover interrupted work with Checkpoint resume

The main operational tradeoff of local extraction is device dependency: the run relies on your computer, Octoparse client, power, and network connection. Octoparse 10.2 reduces the cost of an interruption with Checkpoint resume. For a supported interactive local run, Octoparse records extraction progress such as output rows, loop position, and unfinished work. If the run stops before completion, starting the task again can present two choices:

Resume restores the saved run and continues toward the remaining data.
Re-collect discards the checkpoint and starts from the beginning.

Octoparse validates the checkpoint against the current task before using it. If the task or input URLs changed, the checkpoint is missing or damaged, or the saved state cannot be matched safely, the task must start fresh. Scheduled local runs also start fresh rather than waiting for a resume decision. Checkpoint resume makes longer local collections more practical, but it does not remove the need to keep the device available or verify the final dataset after an interruption.