DEV Community: RemoveBGKit

TikTok Story Viewer Order: What the List Does Not Prove

RemoveBGKit — Mon, 12 Oct 2026 23:02:28 +0000

TikTok Story Viewer Order: What the List Does Not Prove
Someone opens your Story, and the next day their name sits at the top of your viewer list. That feels like an answer. It is not one. TikTok documents that you can see a Story’s view count and the accounts that watched it; it does not document what their order means.
Key Takeaways
TikTok documents a Story’s view count and viewer accounts. 
Our retained official source describes no ranking formula for that list. 
A list position proves neither repeat visits nor intent. 
A creator’s viewer list is not a tool’s Story results. 
Two different lists get called “viewer order”
First decide which list you mean. The creator-side list names the accounts that watched your Story and belongs to the account owner. A public Story viewer returns the media available for a creator, and its card order is a display choice, not a record of who watched.
TokViewer displays returned public Story media. It does not expose another person’s private viewer list, and the sequence of its Story cards cannot be used to infer who watched those items. To watch a creator’s current public Story, start with the Story Viewer guide.
What the official instructions say, and what they don’t
TikTok’s official Stories help article explains that you can open your own Story, swipe up and see the view count plus the accounts that viewed it. Our retained copy, captured on October 11, 2026, rendered in Chinese; the wording above is our English paraphrase. Nothing in it describes a sort rule.
Does the top name mean they watch you most?
Not from the list alone. Connecting placement to repeat viewing would need documented visits, a recorded refresh and other factors held steady. A single screenshot has none of that. For documented visibility, see whether someone can see that you viewed their Story.
What our own tests cover
Our October 11, 2026 production checks verified playback of four public Story videos and the display of two photos across two accounts. They did not include creator-side viewer lists, controlled repeat visits or an ordering experiment.
An honest test you can run
Note the app version, audience setting and initial viewer screen. 
Have consenting accounts view in a documented order. 
Capture the viewer screen after each view and after a fixed refresh interval. 
Report only what changed, and keep the screenshots where nothing changed. 
Such a test can show a pattern under those conditions, not a universal formula.
Source: https://tokviewer.app/blog/tiktok-story-viewer-order/

Batch Background Removal with an API: A Folder Workflow

RemoveBGKit — Mon, 12 Oct 2026 20:36:48 +0000

Your script processed several photos, then stopped. Running the folder again should preserve completed downloads and resume uncertain uploads without creating duplicate jobs.

This guide shows developers how to batch remove background through individual API tasks. RemoveBGKit's website processes one image at a time; its Download All button packages icons extracted from one source image. For independent photos, the folder queue belongs to your script.

Key Takeaways

Test representative images before automating.

Keep a stable request ID for each unchanged input.

Save and inspect each image's ZIP before marking it complete.

Test the inputs and prepare your account

Choose a straightforward photo and harder examples with narrow parts or small lettering. Inspect their cutouts on contrasting backgrounds. If important details disappear, solve that problem before repeating the settings across a folder.

Actual single-image result from October 3, 2026, using generic mode and portrait quality through the website. The output is unretouched; the checkerboard shows transparency. Inspect hair and the remaining glasses detail on the right before accepting this sample. This illustrates visual review, not an authenticated API batch benchmark or the fast-quality output of the script below.

Create an API key in your account and check available credits. The current API reserves five credits per image; completed processing consumes them, while terminal processing failure releases the reservation. Website guest trials do not supply API credits.

Use the API reference for current limits and settings. The example uses generic mode and fast quality. Change the helper's options only after testing, and issue new request IDs when image bytes or processing settings change.

Run a folder through the single-image helper

Download the site's TypeScript upload-to-download helper into your working directory. It submits one image, polls its task, and downloads its authenticated ZIP, with bounded retries and checks on returned URL origins.

Use Node.js 22.18 or newer. Put inputs in an images folder, provide RMBG_API_KEY through your server environment, and run this Bash example from that directory:

#!/usr/bin/env bash
set -euo pipefail
: "${RMBG_API_KEY:?Set your private API key}"
mkdir -p results request-ids
for input in ./images/*; do
  [[ -f "$input" ]] || continue
  case "$input" in
    *.png|*.jpg|*.jpeg|*.webp|*.PNG|*.JPG|*.JPEG|*.WEBP) ;;
    *) continue ;;
  esac
  name=$(basename "$input")
  output="results/$name.zip"
  [[ -s "$output" ]] && continue
  idfile="request-ids/$name.id"
  [[ -s "$idfile" ]] || uuidgen > "$idfile"
  export RMBG_REQUEST_ID
  RMBG_REQUEST_ID=$(< "$idfile")
  if node remove-background.mts "$input" "$output.part"; then
    mv "$output.part" "$output"
  else
    printf 'Stopped at %s; retain its request ID.\n' "$name" >&2
    exit 1
  fi
  sleep 4
done

This requires Bash, uuidgen, and the downloaded helper. It handles one flat folder, retains input extensions in output names, and submits sequentially. A ZIP becomes complete only after the helper succeeds and its temporary file is renamed. Run one instance against a dedicated batch folder.

Resume without blindly creating new tasks

Keep originals, filenames, settings, and request-ID files unchanged when restarting after a network error. Completed ZIPs are skipped. An uncertain upload reuses its ID so the API can return the existing task during its retention period.

If processing itself failed, replaying that ID returns the failure; correct the cause and deliberately create a new ID. Authentication, credit, or format errors also need correction. The script stops at an error, preserving earlier downloads for inspection.

Results expire 24 hours after submission, and deduplication is tied to retained task records. This small example is not a permanent job ledger. For production queues and task-status details, follow the complete API recovery tutorial.

For a changed input, move its old ZIP and ID out of the batch folders before submitting it again. Leaving an old ZIP in place would skip the replacement image. Keep separate folders for separate runs. The four-second pause reduces upload bursts, but does not guarantee compliance when other clients share your IP; the helper handles temporary rate-limit responses with bounded retries. A production worker should additionally persist task IDs and explicit review states instead of treating file presence as its whole ledger.

Inspect the downloaded folder

Each ZIP belongs to one input; this is not a combined archive for the whole folder. Extract it and check the PNG against its original. Review fine lettering, narrow connections, and missing internal spaces at the intended display size.

A saved ZIP means transport completed, not that every cutout passed visual review. Keep rejected outputs separate and record the reason. Use the PNG transparency check if a downloaded image still appears white. Your acceptance criteria decide which files reach the final design.

By RemoveBGKit team. Prepared with AI assistance and reviewed against the existing API helper and processing record.

Originally published: https://removebgkit.com/pages/blog/batch-remove-background

Tool: https://removebgkit.com/

Checking Thin Ink Retention in a Background Removal Pipeline

RemoveBGKit — Wed, 07 Oct 2026 03:57:13 +0000

Sparse handwriting poses a useful validation problem: removing the paper is not enough if the same operation also removes the foreground strokes. For our RemoveBGKit pipeline, we checked a small original synthetic ink fixture against the actual production output rather than relying only on a thumbnail.

Disclosure: this is a case from the RemoveBGKit product team. The article was prepared with AI assistance and checked against the processing record. Contact: support@removebgkit.com.

Use a reproducible fixture

The input contains dark line segments and a thin underline on a neutral paper gradient. It is a synthetic test pattern, not a real person's signature. It avoids publishing private handwriting and gives the test a known set of dark pixels to inspect.

We submitted it to the live service on October 7, 2026 using auto mode and pro quality. The submitted task was task_9db198dc6d5b4bafa78853764d3b5db2. Both the input and PNG output measured 720 by 420 pixels.

State exactly what the metric measures

The checker selects input pixels whose maximum RGB channel is below 100, excluding a four-pixel border. It then measures how many selected locations have output alpha above 128. On this fixture the ratio was 1.0. The top-left output corner had alpha 0; the output alpha maximum was 255.

Those checks answer three limited questions: did dimensions change, is a background corner transparent, and are the darkest interior marks still present? They do not measure all paper residue or verify every antialiased edge. They also leave faint and colored strokes outside the dark-pixel mask.

For a separate test, vary those inputs deliberately rather than treating this one ratio as a universal quality score. A dense object, a colorful background, or an already transparent source is a different task from dark sparse ink on light neutral paper.

Preserve the actual output

The output SHA-256 is 15d13c1f4bbe9fe5260123565c50a6effb36b2af5ba66cfec1584a5f8514bd4d. The downloadable PNG is unretouched. The visual comparison only resizes the output and composites it over a contrasting background.

That distinction matters. A presentation image is useful for spotting residue or missing lines, while the original output is what another person needs to inspect the alpha channel or reproduce the measurements.

Keep the workflow honest

For user-facing handwriting, ask the user to inspect letters, dots, loops and faint ends before accepting the cutout. Keep the original and use a clearer scan when important strokes disappear. Our website has no manual restore brush, so a generic promise to repair every signature would be inaccurate.

PNG is an output format that can carry transparency; changing a JPG's format is not the removal operation. A transparent handwriting image is also separate from a document service's identity verification or signing record.

The original guide includes the input, output and processing record: https://removebgkit.com/pages/blog/transparent-signature

Image-format reference: https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types

This comparison is a synthetic test pattern, not a personal signature. Download the unretouched PNG and processing provenance.

When a Background Remover Makes Your Logo Fade

RemoveBGKit — Mon, 05 Oct 2026 14:42:49 +0000

A downloaded PNG can have a transparent background and still be unusable. That happened with our own logo: the background disappeared, but the badge became faint too.

Our general background-removal pipeline needed a different path for flat artwork. We added conservative handling for opaque, limited-color images with a nearly uniform border. Inputs that do not meet those conditions continue through the existing model workflow.

The important distinction

The sample contains a white letter inside a green badge, surrounded by a white canvas. Removing every white pixel would damage the letter. The implementation identifies surrounding, edge-connected background instead, preserving disconnected white artwork inside the badge.

Boundary cleanup handles partially blended pixels along the edge. Those pixels can change; preserving artwork does not mean every pixel remains byte-identical.

Verify the delivered PNG

On October 5, 2026, we tested the deployed auto/pro workflow through our website. The surrounding background became transparent, representative solid-green and white-letter pixels retained their original colors and alpha 255, and dimensions remained 512 by 512.

Output SHA256: 5e3260a508b82090638a8d0c2d1fb01f29f4b8e93c3186433069877443d098d3. The actual file and short website workflow are available in our transparent-logo tutorial.

This verifies one flat-logo case. Gradients, shadows, and complex artwork may behave differently. Check the exported image on its destination background.

Published by the RemoveBGKit team with AI assistance. We operate the service discussed here. Contact: support@removebgkit.com.