tryingopen
Sending pictures and PDFs, and getting files back
What you can attach on tryingopen, which 13 models read pictures, how PDFs are read, and how files a model makes open safely in your browser.
A message on tryingopen can carry pictures and PDFs, and many of the models can hand you a file in return. Here is how both directions work, as of October 2026.
What you can attach
Each file is a PNG, JPEG, GIF or WebP image, or a PDF, at most 5 MB. You add them in any of these ways:
- Paste them into the message box.
- Press the clip button.
- Drag them onto the composer (since August 26, 2026).
A message takes up to 3 files, and so does a whole chat. Each turn resends the conversation so far, attachments included, so a fourth file anywhere in one chat is refused with "Please attach at most 3 files."
The clip button follows the model you picked. With a model that reads pictures it says "Attach a PDF or image". With a text-only model it says "Attach a PDF", and a picture added anyway gets a note that the model can't read images. A Word file or a 6 MB photo is turned away in your browser with a message saying why.
The 13 models that read pictures
Thirteen of the 24 models you can pick read pictures on tryingopen:
| Model | Maker | Also in Self Chat |
|---|---|---|
| LFM2.5-VL 3B (on our edge devices) | Liquid AI | No |
| GLM 5.3 Flash | Z.ai | Yes |
| Qwen3.8 Flash | Alibaba | No |
| Qwen3.8 27B | Alibaba | Yes |
| Gemma 4 31B | No | |
| Gemma 4 26B | No | |
| DeepSeek V4.1 Flash | DeepSeek | Yes |
| Inkling | Thinking Machines | Yes |
| Mistral Large 4 | Mistral AI | No |
| MiMo V2.6 Flash | Xiaomi | No |
| MiMo V2.6 Pro | Xiaomi | No |
| Ling 3.0 Flash VL | inclusionAI | Yes |
| Inkling Small | Thinking Machines | Yes |
The other eleven are text-only here, and the composer takes PDFs for all of them. The tour of the picker lists them by group.
Two of them need a word. Google's Gemma 4 E2B takes images, but our boards run it without a vision projector, so there it reads text alone. OpenRouter lists Muse Glimmer 30B as taking images, yet asked what colour a solid blue PNG was, its endpoint answered "I don't see an image attached to your message." We switched its upload off.
Pictures on the default pick
The default pick, LFM2.5-VL 3B, pairs a 2.6B-parameter language model with a 400M-parameter vision encoder, so it reads pictures on the edge device itself. Liquid AI's d1 first decides whether the small model or your cloud fallback takes the turn, and reading or describing a picture is on its list for the small model (how d1 routes).
d1 reads text alone. The reply's Learn more panel says what it gets instead: "A picture is described to it as 'the user attached an image' and never sent." If the turn goes to the cloud, the picture travels with it to your fallback. GLM 5.3 Flash, the default fallback, reads pictures too. The clip button goes by the small model, so with a text-only fallback a picture can still be sent to a model that can't read it.
PDFs
How a PDF is read depends on the route your message takes.
Through OpenRouter, a PDF first goes to OpenRouter's file parser, which turns it into text that any model can read, the text-only ones included. Our privacy policy says the parser "also sits outside the zero-retention requirement." What zero data retention covers explains where that line falls.
Models reached through ngrok's AI gateway skip that parser. With no provider picked, the models labelled "Provider may log" (Mistral Large 4 aside) go to their host's own API, and Gemma 4 31B, Gemma 4 26B and GPT-OSS 120B on "Let OpenRouter choose" go to Amazon Bedrock. On that route the PDF reaches the host as a file, and how it gets read is up to that host. Picking a provider, where the model lists any, sends the PDF through OpenRouter's parser.
A PDF changes a few other things:
- On the default pick, a PDF sends the turn to your cloud fallback. d1 isn't asked, because only the cloud path reads PDFs, and the reply records that reason. The default fallback, GLM 5.3 Flash, takes the gateway route unless you pick a provider for it.
- The side-by-side sits out any chat with a PDF in it, since the small model on the boards reads text and pictures only.
- Self Chat refuses PDFs and its clip button offers images only, because a PDF would reach a parser its zero-retention promise doesn't cover.
If you press Compare under a reply, the closed model gets the same attachments your open model had (Compare has the details).
Files the model makes
Ask a capable model for a file, say "a one-page resume I can save as a PDF", and it calls tryingopen's file-making tool. The file shows up as a card in the reply, and opening it slides a panel in beside the chat. Previews arrived on August 18, 2026, the day after launch.
| File | How the panel shows it |
|---|---|
| Web page | Rendered live, scripts and all |
| Document | Rendered as a sheet of paper, with a Save as PDF button |
| SVG | Shown as an image |
| CSV | Shown as a table |
| Markdown | Rendered, with headings, lists and links |
Each file has a Source toggle for the raw text and a Download button, and web pages and SVGs get a Print button. Save as PDF opens your browser's print dialog, where you can save the page as a PDF.
When a model names its file resume.pdf, the panel explains: "Models can only write text, so it is saved as HTML: use Save as PDF below to get a PDF."
Which models can make files
Every cloud model in the picker has the tool except Nemotron 3.5 Lightning. Its endpoints don't call a tool unless forced to, so we offer it as a plain chat model. Three provider pairs also run without tools, because those endpoints don't take them: Gemma 4 26B on CoreWeave, GPT-OSS 120B on SiliconFlow and Inkling on DeepInfra. Turns answered by the small model on an edge device have no tools either. When d1 sends a turn to your cloud fallback, that model brings its tools along.
How a preview stays walled off
A file a model wrote can contain code, and a web page runs its scripts when it renders. So web pages, documents and SVGs (an SVG can carry a script of its own) render inside a sandboxed frame:
<iframe sandbox="allow-scripts allow-modals allow-popups allow-forms" srcdoc="…"></iframe>Markdown and CSV previews are drawn by the page itself, as formatted text and a table.
The permission left off that list does the work. Without allow-same-origin, the browser puts the frame in an opaque origin of its own. Scripts inside can run, but they can't reach tryingopen's page, its storage or your conversation. Granting allow-same-origin next to allow-scripts would let model-written code climb out of the sandbox, so it stays off.
Even printing respects that wall. Our page can't reach into the frame, so Save as PDF sends it a message, and a short script inside the frame opens the print dialog.
The file arrives inside the model's streamed reply, and your tab builds the preview and the download from it. As the privacy policy puts it: "Files the model creates, their previews, and exports are put together in your browser and saved straight to your device."
In Self Chat, the pictures you attach and the files the model makes also land in the chat's artifacts folder, in the storage you chose. Sharing a chat, a model setup or a preset as a link covers share links, which leave attachments out, and the Export button.