OhMyShot Local Export or Cloud Upload? Check Sharing First

Use a local export when you want to review an OhMyShot screenshot before deciding where it goes. Use Cloud Upload when you deliberately want an externally hosted image link. OhMyShot’s current README says the app works offline by default, but enabling Cloud Upload sends a screenshot to ImgBB. Before capturing anything sensitive, check the Sharing settings—not just the button you plan to press—because the release history also documents automatic upload after Capture & Beautify.

This guide is for support teams, developers and documentation writers who already use OhMyShot and need to hand off the right copy. The goal is a deliberate choice between an inspected file and a hosted link, not a promise that any sharing route is automatically private. For capture and annotation basics, use our single-screenshot workflow.

Auto-Bot.io publishes this source-backed editorial guide. We checked the OhMyShot README and release history on October 18, 2026; this is not a hands-on audit of desktop builds or ImgBB access controls. The hero is a concept illustration, not an OhMyShot screenshot.

1. Choose the output before handling the screenshot

OhMyShot brings capture, crop, annotations and export into one desktop workflow. Its documented PNG/JPEG exports and copy actions let you prepare an image without needing a hosted link. Optional Cloud Upload is useful when the intended audience needs a URL instead of an attachment. These outputs solve different handoff problems:

Saved PNG or JPEG: use a file when you want to reopen and inspect it, then attach it through an approved channel. Check the actual saved image, its folder and the destination’s audience. A cloud-synced folder is not an offline-only destination.

Copied image: use image pixels for a quick paste into the intended ticket, document or conversation. Check the pasted preview: it should contain the reviewed image, not an older capture or a text link.

Cloud Upload link: use a URL when the image is approved for external hosting. Check upload settings, the exact hosted image and the host’s access and retention options. A link is not an access-control policy.

Saving locally is a useful review checkpoint, not a confidentiality guarantee. Attaching that file to a ticket or pasting it into a chat sends a copy to that destination; clipboard tools and synchronized folders can introduce their own sharing behavior. Choose the destination under your team’s rules rather than relying on the word “local.”

2. Check Sharing and auto-upload before capture

The v1.11.0 changelog, dated February 17, 2026, documents Cloud Upload through ImgBB, a Sharing setting to enable or disable upload, an auto-upload toggle, auto-copying a link, and a tray action named Upload Last Screenshot. It specifically describes auto-upload after Capture & Beautify. These are documented controls to check in your installed build, not a claim that every version or language has identical labels.

1. Open the app’s Sharing settings before a sensitive capture. Check both whether Cloud Upload is enabled and whether automatic upload after beautifying is enabled.
2. For a review-first workflow, turn automatic upload off. If no external hosting is needed, leave Cloud Upload disabled as well. Do not assume that avoiding a manual Upload action is enough while an automatic route is enabled.
3. Check auto-copy behavior. If you expect to paste image pixels, make sure the clipboard will not instead contain an automatically copied hosted link. Inspect what arrives in the destination.
4. If you cannot establish the settings, use a non-sensitive test capture first. Do not learn whether your build uploads automatically by capturing a real customer record or a credential.

“Offline by default” describes the default workflow, not every optional action. The privacy page, labeled January 2026, uses broader wording including “No cloud storage”; the current README explicitly states the optional ImgBB upload exception. For this sharing decision, account for that exception. It does not mean local editing requires cloud hosting.

3. Prepare a reviewable copy, not just a prettier source

Start with sample data in a test account whenever practical. For a public support example, a demo record is easier to review than a real customer screen with many details covered afterward. If you must capture a production screen, get the appropriate permission and remove unrelated information before capture.

• Capture only the necessary region or window. Exclude unrelated tabs, notifications, sidebars and conversations.
• Crop unnecessary sensitive areas out. If removing an area would destroy the evidence, consider recreating the problem with safe test data instead.
• Use annotations to explain the issue. An arrow or outline can identify a control, but an outline is not a redaction. Do not rely on soft blur, a highlighter or a partially transparent shape to protect a secret.
• Review the complete image. Check names, addresses, tokens, internal URLs, QR codes, filenames and background windows—not only the central issue.

Opacity deserves particular attention. The v1.26.2 release, published September 9, 2026, says rectangle and ellipse fills now match the selected transparency level, including fully transparent fills while outlines remain visible. A visible border therefore does not prove the area inside it is hidden. This release note is not a certification that shapes provide secure redaction.

4. Save, reopen and inspect the file you will send

Save a local PNG or JPEG to a deliberate folder. PNG is a useful starting choice for interface text; the important check is whether the actual export is readable and contains only the intended content. Choose a non-synchronized local folder if your requirement is to avoid a cloud copy during review.

1. Use a distinct review filename. For example, checkout-error-demo-reviewed.png is easier to distinguish from a raw capture than several files named “Screenshot.” This is a naming suggestion, not an OhMyShot requirement.
2. Reopen the saved file outside the editor. Check every edge, crop, annotation and area intended to be hidden. Inspect at a readable size as well as the width at which the recipient will see it.
3. Keep the source and approved output distinguishable. If a raw capture must be retained, keep it in your approved restricted location—not beside the public attachment under a confusingly similar name.
4. Attach only the inspected output. Read the attachment filename and preview before submitting the ticket or post. A correct editor preview does not prove that the selected attachment is the same copy.

For two-state evidence, our Expected/Actual combining guide covers the separate job of arranging captures into one readable attachment. Apply this output review to the combined result too; a clean first panel does not clear the second one.

5. Create a hosted link only when that is the intended handoff

If a URL is useful and external hosting is allowed, OhMyShot’s optional Cloud Upload avoids a separate manual image-hosting handoff. Its README identifies ImgBB as the destination. Start with a non-sensitive example and confirm which current image your installed build will upload; do not use Upload Last Screenshot without verifying what “last” refers to.

1. Approve the content for that host and audience first. A private support conversation does not automatically authorize an externally hosted copy.
2. Upload the intended reviewed image, then open the returned link. Check the actual hosted pixels, not merely the success message or a history thumbnail. Compare the content and annotations with the output you approved.
3. Keep the link tied to the correct report. Paste it into the intended destination, inspect the resulting preview and confirm it is not a link from an earlier task.
4. Check any required expiry or deletion controls explicitly. ImgBB’s API documentation describes optional expiration and returns image-management information, but that does not establish which options OhMyShot exposes or applies to your upload. Do not promise automatic deletion or restricted access without checking the actual route.

A hosted link is convenient for approved public examples. For confidential material that requires a particular authenticated audience or retention policy, use your organization’s approved attachment or sharing system instead of assuming an image-host URL satisfies those requirements.

Worked example: one checkout error, two audiences

Suppose a customer reports a checkout error. The original capture shows an email address and an order reference, but the public bug report only needs the error banner and the button below it. This is an illustrative editorial scenario, not a customer incident or an executed OhMyShot test.

• Before capture: disable auto-upload for the review workflow. Reproduce the error with a demo account and sample order if possible; otherwise keep the original within the authorized support process.
• Public copy: capture the relevant error area using safe data, add one arrow without covering the error, save checkout-error-demo-reviewed.png locally and reopen it.
• Internal ticket: attach the reviewed file through the team’s approved ticket system. Include the error text and reproduction steps in writing; do not rely on the image alone.
• Public issue: attach that approved demo file directly, or deliberately use Cloud Upload if ImgBB hosting is appropriate. Open the resulting attachment or link and verify the same demo content appears.

The original customer capture and the public demonstration have different audiences. A clearer arrow does not change that boundary. The useful checkpoint is being able to identify the exact output you approved and the exact copy the reader receives.

Questions before you share

Why did a paste insert a URL instead of the picture?

Check whether you copied a Cloud Upload link or have auto-copy-link enabled in Sharing. The release history documents that option. Copy or attach the intended image instead, then inspect the destination preview. Do not assume the clipboard still contains what you copied in an earlier step.

Does deleting the local file or an Upload History entry revoke a link?

Do not treat either action as proof that the hosted image is gone. The changelog lists history copy/delete/open actions but does not establish a remote-deletion guarantee. Use the host’s actual removal process when needed and verify the result; recipients may already have retained a copy.

What if I already uploaded the wrong screenshot?

Stop sharing that link, follow your team’s incident process and use the host’s available removal controls. If an exposed credential is involved, revoke or rotate it through the owning service; covering it in a later image does not revoke the earlier exposure. Prepare a fresh safe example only after addressing the mistaken upload. Do not claim that deleting a link recalls every copy.

Make the next handoff deliberate

For your next non-sensitive screenshot, check Sharing first, save and reopen one local output, then choose whether the recipient needs an attachment or a hosted link. Use OhMyShot’s capture, annotation and export tools to make the explanation clearer without letting presentation obscure where the image goes.

Get the current OhMyShot release for macOS, Windows or Linux, and try this review-first workflow with sample data. Our OhMyShot overview introduces the desktop tool; the current project README supplies the optional-upload qualification that should accompany older blanket offline descriptions.