Focused utilities · no account

Small tools. Serious work.

Work with documents, images, text, code, campaigns, and everyday calculations directly in your browser.

Local processingNo setup

PWRKIT is a collection of 74 focused browser utilities for common PDF, image, text, developer, marketing, and calculation tasks. Every tool is available without an account, trial, or subscription, so you can move from a specific problem to a usable result without setting up a larger application.

Each file tool identifies whether it runs in the browser or uses a private worker. Browser-labeled operations keep source files on the device. Private-worker routes upload a file for temporary processing and remove the job directory afterward. Text transformations and calculations run on the device. Each tool explains its controls, keeps the original input unchanged, and provides related utilities for the next step. Read the privacy policy for details about file handling, analytics, and stored search activity.

Common questions

Common questions

Answers about privacy, access, and how the tools work.

Do I need to create an account?

No. Every PWRKIT utility is available without registration, a trial, or a subscription.

Are my files uploaded?

Each file tool states its processing method. Browser-labeled operations keep files on your device. Tools labeled private worker upload the file for temporary processing and remove the job directory afterward.

Can I use PWRKIT on a phone?

Yes. The catalog, search, workbenches, and downloads work on mobile and desktop browsers.

How are new tools added?

Each utility is an independent module. New tool folders are discovered during development and production builds, which keeps the catalog consistent as it grows.

PWRKIT groups small browser tasks by outcome rather than by software package. Begin with the thing you want to produce: one combined PDF, a smaller image, corrected text, readable developer data, a tagged campaign link, or a checked calculation. Search accepts ordinary task words, so a query such as merge, WebP, timestamp, or discount leads to the matching workbench. This approach is useful when the job is clear but the name of the operation is not.

Each tool keeps its controls on a single page. You can inspect the required input, change the available options, run the operation, and review the result without creating a project or account. The narrow scope also makes it easier to notice what the tool does not do. A PDF page extractor selects pages but does not edit their contents. A JWT decoder displays claims but does not verify the token signature. Clear boundaries matter when a result will move into another system.

If two tools sound similar, identify what must remain unchanged. Resizing changes pixel dimensions, while cropping removes an outer area. Compressing targets file size, while converting changes the file format. Splitting a PDF produces separate files, while extracting pages creates a new document from a chosen subset. The category guides explain these decisions in more detail, and every tool page describes its own controls, limitations, and result checks.

The PDF workbenches cover page-level jobs that often appear between scanning, reviewing, and sharing a document. Merge PDF combines several files in a chosen order. Split PDF separates a document into individual pages or selected ranges. Extract PDF Pages keeps only the requested pages in a new file, while Remove PDF Pages does the inverse. Rotate PDF corrects orientation, and Compress PDF attempts to reduce storage or transfer size within the limits of browser processing. A reliable document workflow begins before the button is pressed. Check that the source opens normally, is not encrypted, and has the page count you expect. Put merge inputs in the intended sequence. Write page ranges against the displayed page numbers, not numbers printed inside the document, because cover sheets and inserts can make those differ. After download, open the new file and compare its first page, last page, total count, orientation, and ordering with the plan.

Browser processing keeps compatible PDF files on the device, but local processing does not remove every risk. A shared computer can still retain downloads. A browser tab can expose visible material to someone nearby. A damaged or unusually large file can exceed available memory. Keep the original, use a private device for confidential work, and follow workplace rules that apply to document handling. PWRKIT does not silently replace the source file, which leaves the final save or replacement decision with you.

Image tasks usually concern dimensions, framing, file size, format, appearance, or embedded information. Resize Image changes width and height. Crop Image keeps a selected rectangle. Compress Image trades some encoded detail for a smaller file. The JPG, PNG, and WebP converters create a copy in a different browser-supported format. Blur Image softens the full picture, Image Color Picker samples a pixel, and Remove Image Metadata re-encodes the picture before it is shared.

The destination should guide the choice. A marketplace may require exact pixel dimensions. A website may need a smaller transfer size. A graphic with transparency may need PNG or WebP rather than JPEG. A photograph sent by email may benefit from JPEG compression.

Converting every file to the newest format without checking the destination can create compatibility problems, while repeatedly saving a lossy format can add visible artifacts. Keep one unchanged source and make delivery copies for each use.

Preview the output at the size people will actually see. Zooming far beyond normal use can exaggerate small compression marks, but checking only a tiny thumbnail can hide text damage or rough edges. Confirm width, height, file type, transparency, framing, and readable detail. Metadata removal should also be treated as a new export, not proof that every possible trace has vanished. The tool re-encodes the pixels, and the downloaded copy still needs a filename and storage location appropriate for the material.

Text tools help with measurement, cleanup, presentation, and transport formatting. Word Counter and Character Counter report length without rewriting the input. Case Converter changes capitalization patterns. Remove Duplicate Lines keeps the first occurrence of repeated lines. Markdown Preview renders sanitized HTML beside the source. HTML Escape turns reserved characters into entities, and the URL encoders convert text to or from percent-encoded form. These jobs may look small, yet an unnoticed space or character can affect a form, link, or published page.

Developer tools focus on data that needs to be read, tested, or generated. JSON Formatter parses the input before formatting or minifying it. Regex Tester applies a JavaScript regular expression to sample text and reports matches. Base64 tools translate between UTF-8 text and an encoded representation. Timestamp Converter compares Unix values with readable dates. Hash Generator creates a cryptographic digest, UUID Generator creates version 4 identifiers, and JWT Decoder displays the three token sections without claiming that the signature is valid.

Encoding, hashing, and encryption solve different problems. Base64 changes representation and can be reversed by anyone. URL encoding protects reserved characters inside one URL component, but it does not validate the destination. A hash is one-way output used for comparison or identification; it does not hide a message in a recoverable form. A decoded JWT payload is readable data supplied by the token issuer, not verified identity. Tool pages state these distinctions near the relevant workbench so the output is not mistaken for a security guarantee.

Marketing work often moves through a chain of small checks. UTM Builder appends named campaign parameters to a destination URL. QR Code Generator turns a link or short text into a downloadable code. Hashtag Generator normalizes a topic list. Meta Tag Preview shows a search-style title and description, while OpenGraph Preview shows a representative social card. The previews help with drafting, but Google and social platforms can crop, cache, omit, or rewrite what they display.

Use campaign tools as preparation rather than final approval. Establish naming rules for source, medium, and campaign values before building links, because inconsistent spelling fragments reports. Test a finished URL in a private browser window. Scan a QR code from the printed size and distance that will be used. Review titles and descriptions for meaning before counting characters. After deployment, inspect the public page on the destination platform, since a local preview cannot reproduce every crawler, cache, or account setting. The calculator group answers percentage, tax, price, date, age, loan, compound interest, and BMI questions. Every result depends on the entered values and the model behind the form. Check units, rate periods, inclusive or exclusive tax mode, date boundaries, contribution timing, and rounding. Financial and health outputs are estimates, not professional advice. A useful calculation records both the result and the assumptions, making it possible to explain why another spreadsheet, lender, tax rule, or clinical assessment produced a different number.

Each file tool states where processing occurs. A browser-labeled operation uses local memory and creates a downloadable result while the input stays on the device. A private-worker route transfers the selected input to an isolated service, processes it in a temporary job directory, and deletes that directory afterward. Text transformations, developer utilities, campaign builders, and calculations operate on the device unless the page states otherwise.

Local processing has practical limits. Available memory depends on the device, browser, open tabs, and source size. Supported image formats depend on what the browser can decode and encode. An encrypted or malformed PDF may fail before page operations begin.

Clipboard and download behavior can vary with browser permissions. If a workbench reports an error, reduce the file size where appropriate, close unneeded tabs, confirm the format, and try an updated browser before assuming the source is permanently unusable.

Privacy also extends beyond network transfer. Screen recordings, browser extensions, operating-system backups, download folders, and shared-device access can expose material processed locally or returned by a private worker. Organizations may prohibit browser utilities even when processing is local. Follow those rules, avoid confidential input on an untrusted device, clear the workbench after use, and move or delete downloaded copies according to the applicable retention policy. The privacy page explains analytics and first-party logs separately from tool processing.

A successful status means the workbench completed its operation. It does not prove that the result fits a later application, policy, or publishing context. Open downloaded files before deleting a source. Paste transformed text into a temporary field before replacing a document. Compare calculated values with the stated formula and units. Test campaign links after all redirects. For developer data, validate the output in the parser, runtime, or service that will consume it.

Verification should match the cost of an error. A draft social image may need a quick visual check. A signed contract packet needs page-by-page confirmation. A loan comparison needs independent review of fees, compounding, and lender terms. A JWT used during debugging must still be verified by the receiving application. A BMI result should be discussed with a qualified professional when it affects a health decision. The tool supplies an operation or estimate; the surrounding decision remains with the person using it.

Keep a short record when the work matters: source filename or value, chosen settings, output filename, date, and the check performed. This is especially helpful when several similar copies exist or when a result is handed to someone else. PWRKIT leaves original input unchanged, so you can return to the source if a destination rejects the output. Related-tool links are provided for the next operation, but each new transformation should be reviewed again rather than assumed safe because the previous step succeeded.

Every utility lives as a separate module with its own metadata, validation, processing logic, workbench, and supporting explanation. The build discovers those modules and produces the catalog from the same source used by the routes. This reduces the chance that a tool exists without a card or that a card points to a missing implementation. Separate modules also keep a change to one operation from silently altering the controls or copy of an unrelated tool. New entries are added when a task can be explained with a narrow input, an understandable result, and clear limits. PWRKIT does not try to reproduce a full document editor, design suite, development environment, campaign platform, or financial system. Those products are appropriate when work needs collaboration, account history, advanced editing, automation, or regulated records. The catalog is for the smaller job that benefits from a direct workbench and an output you can carry elsewhere.

Supporting content is reviewed when browser behavior, technical dependencies, tool controls, or policy details change. Each tool shows an update date, and the editorial standards page describes corrections and review principles. Problem reports can identify a tool, browser, device, expected result, and observed result without attaching confidential input. This feedback helps distinguish a copy problem from a browser limitation or processing defect. The contact page also accepts accessibility reports, privacy questions, and corrections to published explanations.