# TxtNet Browser: Web Browsing Through SMS on Android > TxtNet Browser is an Android client for requesting web pages through SMS rather than mobile data or Wi-Fi. It can connect to public servers or use a second Android phone as a self-hosted TxtNet Server, with important limits around encryption, SMS reliability, and JavaScript-driven sites. **lukeaschenbrenner/TxtNet-Browser** — An app that lets you browse the web over SMS - Repository: https://github.com/lukeaschenbrenner/TxtNet-Browser - Stars: 1,540 · Forks: 37 - Language: Java - License: GPL-3.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/lukeaschenbrenner-txtnet-browser ## TxtNet Browser's SMS Request Path TxtNet Browser addresses a specific connectivity problem: opening a read-only web page when the client phone has SMS service but no usable mobile data or Wi-Fi connection. It is aimed at users who can exchange ordinary text messages with a separate phone that has internet access. That second phone can be a public server operator or a user-controlled TxtNet Server host. The application supports only HTTP GET requests. It does not present itself as a full replacement for a conventional Android browser, and the README contains no documentation for POST forms or other request methods. This restriction follows from the SMS protocol design. Each requested URL is encoded with a custom Base-114 format, derived from Basest, and sent to a registered server phone number. A request usually fits into one SMS, but the protocol adds an order specifier so segmented traffic can be reconstructed. The client receives numbered response messages and parses the returned representation for display. Pages are not delivered as ordinary web traffic between the client phone and a website. The server phone fetches the page and returns reduced HTML over SMS, which makes SMS throughput and carrier behavior part of the browsing experience rather than background implementation details. ## WebView Fetching and HTML Reduction TxtNet Server performs the network-side work inside its Android host. According to the README, it uses an Android WebView component to request the destination site in a way intended to resemble a regular browser request and avoid some restrictions imposed on simpler HTTP clients. Cloudflare is specifically mentioned as an example of a service that may impose such restrictions. The WebView also allows JavaScript to run on the server phone. This explains an otherwise surprising part of the design: the README says JavaScript and CSS are removed from the transferred page, while sites requiring JavaScript can still render. Dynamic content can execute in the server-side WebView, and only the resulting HTML is reduced and sent to the client. The client does not receive the site's JavaScript bundle for execution. After loading, the server removes media content, JavaScript, CSS, unnecessary tags, and some attributes. It compresses the HTML as raw bytes with Google's Brotli algorithm and encodes the result with the custom Base-114 format. It then splits the encoded response into numbered segments of 160 characters to maximize the GSM-7 SMS capacity. This pipeline reduces payload size, but it also means that CSS-dependent presentation and interactive browser behavior are outside the transferred result. ## Public Servers and Second-Phone Self-Hosting The client can communicate with a public TxtNet Server, and the README lists a United States number at +19134908639. Its availability is not guaranteed, and the listed note says that AT&T is supported while T-Mobile currently has problems. The README also warns first-time users that public instances may not work for them. Carrier compatibility therefore needs checking against the note rather than being inferred from the existence of a public number. For a self-hosted setup, TxtNet Server runs as a background service in the app. It uses the primary mobile number associated with the active carrier subscription SIM. The hosting phone needs an internet connection and SMS service, while client phones need SMS access to that number. The README recommends using a second phone on the same carrier as the primary number when compatibility needs to be more predictable. This architecture is easy to misunderstand. The phone sending page requests does not fetch destination websites itself. Another phone receives those requests through SMS, loads the page using its WebView and connection, then sends the processed HTML back. The approach distributes infrastructure, but it does not create a direct end-to-end encrypted session between the client device and the destination website. ## APK Installation and Initial Server Setup There is no documented build or installation command for the Android client. The README directs users to the GitHub releases page for an APK and states compatibility with Android 4.4 KitKat and later. It does not document installation from source, Gradle usage, signing configuration, or Google Play availability. The client and server should therefore be installed from the project-provided APK rather than from an invented command. For a first real use, open the installed app and add a server phone number. The README does not provide exact navigation labels for client-side server registration, so the article cannot safely invent a menu sequence for that step. Select the public instance documented by the project or plan to use a second phone as the server. To host a server on Android, open the overflow menu and select "TxtNet Server Hosting." Grant the permissions requested by the app, then use the "Start Service" toggle. The README says Android 4.4 through 6.0 require one-time `adb` commands specified by the app. Android 6.0 through 10.0 may also use Skizuku, although a PC is still required once. Android 11 and later can use Shizuku without a PC. Since the repository does not include the actual `adb` command or the in-app instructions in the app, no command should be reconstructed here. After the service starts, a client should request a small, HTML-oriented page from the hosting phone number. If loading stalls, the README specifically recommends increasing "SMS Send Interval" on the server. ## Carrier Limits and Failure Modes SMS is the main source of unreliability. The README says some carriers rate-limit incoming text messages, which can make a large page appear stalled while the server sends its response. Increasing "SMS Send Interval" may reduce that symptom. This is a mitigation, not confirmation that every carrier will deliver the full response. Congested mobile networks may drop one or more segments. The app currently has no logic to recover from a missing message, so a substantially stalled page must be requested again. Because the client cannot fetch the page directly after sending the SMS request, that retry depends on the server path remaining available. Android 12, or possibly a newer version of Google Messages, can block messages from a number without applying the normal blocked-message behavior expected by TxtNet Browser. In that case, no response reaches the client and the app appears unable to load pages. The documented workaround is to silence notifications from the server phone number instead of blocking it. The response pipeline also removes JavaScript, CSS, and media from the transferred HTML. A site may render on the server-side WebView and still provide a diminished result on the client. Interactive workflows, video, images, and CSS-dependent interfaces are therefore poor candidates, even if their underlying HTML can be fetched. ## Plaintext Transport and GPL-3.0 Obligations The README explicitly states that web traffic over this system should be considered unencrypted because requests travel through SMS and arrive at the server in plaintext. Users should not place passwords, authentication tokens, private queries, or sensitive documents into the destination URL or otherwise rely on this path to protect them. The server phone and carrier path are central to the exchange, and the documentation does not claim end-to-end encryption from client to destination website. The repository is licensed under GPL-3.0. That matters for engineers who modify or redistribute the software, especially when incorporating application code into another product. This review does not provide legal advice, but license obligations should be reviewed before changing or redistributing the project. The top-level `requirements.txt` belongs to older tooling around the deprecated desktop server context. It lists packages including `quart`, `twilio`, `pyppeteer`, and `requests`. The README says the desktop Python server is deprecated and that the current server can be hosted in the Android app. The presence of those Python dependencies does not make them the documented installation path for the present client. ## Release State and Alternative Request Paths The repository is not archived, and the last push was on 2026-04-08. Releases include v3.0.3 on 2026-04-08, v3.0.2 on 2026-03-30, and v3.0.1 on 2025-03-02. Those dates show recent release activity, but the README still labels server hosting as an early-stage feature likely to contain issues and points readers to a discussion for development status. Recent releases should therefore be checked against the specific hosting workflow being planned. A real alternative is a conventional browser using Wi-Fi or mobile data. That route fetches pages directly, supports the site's full client-side stack, avoids SMS segmentation and delivery delays, and does not route requests through a server phone. The tradeoff is that it requires the connectivity that TxtNet Browser is designed to work around. Another alternative is reducing the page before transfer through a desktop proxy or server with compression and HTML filtering. That also depends on external infrastructure and remains limited by the return channel if that channel is SMS. TxtNet Browser's distinction is that the host can be another Android phone, and its WebView performs the destination request on that phone. This convenience comes with carrier exposure, plaintext handling, a GET-only protocol, and a reduced HTML result. ## Conclusion TxtNet Browser fits users with an Android phone, working SMS service, and a reliable server phone, especially where mobile data is unavailable or unaffordable. It is a poor choice for confidential browsing, modern applications centered on JavaScript, or networks that delay or drop messages. Before adoption, verify carrier compatibility, SMS charging and rate limits, the security implications of plaintext transport, and whether the documented release remains suitable for the devices in use. For sustained access to interactive or media-heavy sites, choose an ordinary browser connection instead. ## FAQ ### How do I install TxtNet Browser on Android? The README directs users to the GitHub releases page for an APK. It states compatibility with Android 4.4 KitKat and later, but does not document a source build or Google Play installation. ### Can I use a second Android phone as the TxtNet Browser server? Yes. The built-in "TxtNet Server Hosting" service uses the active SIM's primary number, but the host phone needs internet and SMS connectivity. The README describes this feature as an early-stage area with likely issues. ### Why does a TxtNet Browser page stall while loading? Incoming-message rate limits can make loading appear stalled, and a congested network can drop one or more SMS segments. The README recommends increasing "SMS Send Interval" for rate limiting and requesting the page again after a long stall. ### Is TxtNet Browser traffic encrypted? No. The README says to consider all traffic unencrypted because requests are made over SMS and received in plaintext by the server. Sensitive browsing and credentials should not depend on this transport. ### Does TxtNet Browser support normal JavaScript websites? JavaScript can execute in the server-side Android WebView, allowing dynamically loaded HTML to reach the client. The transferred result still has JavaScript, CSS, media, and unnecessary tags removed, so full interactive or styled behavior is not preserved. ## Sources - [Issues](https://github.com/lukeaschenbrenner/TxtNet-Browser/issues) - [License: GPL-3.0](https://github.com/lukeaschenbrenner/TxtNet-Browser/blob/master/LICENSE) - [lukeaschenbrenner/TxtNet-Browser on GitHub](https://github.com/lukeaschenbrenner/TxtNet-Browser) - [README](https://github.com/lukeaschenbrenner/TxtNet-Browser/blob/master/README.md) - [Releases](https://github.com/lukeaschenbrenner/TxtNet-Browser/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lukeaschenbrenner-txtnet-browser